Re: possible design weekness

[Brian Gough <bjg@network-theory.co.uk>]

At Fri, 9 Mar 2007 14:58:39 +0100,
Alxneit-Kamber Ivo wrote:
> I have recently been bitten by what seems to be a design weekness in how
> the functions (function to be minimized, or system of ODE's) are
> defined. These function do not return a status value but the function
> value. This prevents to easily notifiy the caller (iterate) of a failure
> such as e.g. a domain error of one of its arguments or a failed
> malloc().

Hello,

For a domain error the function can return NaN, and the driver routines
should handle this (if they don't we should fix them).

For those functions that return a double there is a tradeoff between
generality and convenience.  As you point out, it is more general to
always return a status value, and the functions have been written from
the point of view that it is more convenient for the user to work with
functions that return a double, as for the standard library functions
- sin(x), log(x), etc.

Most of the time the functions do not do memory allocation or need to
signal other errors, apart from domain error, and it is convenient to
be able to write y=f(x).

I don't think there is any straightforward way to handle the two
possibilities in the same framework.  What I had in mind was that NaN
be used as an error (additional information can be passed back through
the *params argument if needed) and that the routines should return
with GSL_FAILURE if they receive a NaN.

-- 
Brian Gough