This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: possible design weekness
- From: Brian Gough <bjg at network-theory dot co dot uk>
- To: <gsl-discuss at sources dot redhat dot com>
- Date: Mon, 12 Mar 2007 21:25:58 +0000
- Subject: Re: possible design weekness
- References: <1173448719.10868.3.camel@pc446.psi.ch>
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