I do get an error code out, GSL_EFAILED. I'm not really sure what's going on,
but I think:
nmsimplex_iterate calls:
contract_by_best calls eval
gets Nan.
calls gsl_finite
sets status = GSL_EBADFUNC;
returns
if (status != GSL_SUCCESS) GSL_ERROR ("contraction failed", GSL_EFAILED);
In short, iterate gets the Nan, throws EBADFUNC, then gets EBADFUNC and throws
EFAILED.
So, obviously I misunderstood the error handing mechanism. I assumed it was
passed via a static variable like errno, But I guess I need to set an error
handler if I want to properly save the error? It seems to me that in that case
it would still get overwritten by nmsimplex_iterate and contract_by_best....
Jim
________________________________________
From: address@hidden address@hidden on behalf of Patrick Alken address@hidden
Sent: Friday, February 07, 2014 3:02 PM
To: address@hidden
Subject: Re: [Help-gsl] Doing multimin, but my error gets coverted to
GSL_EFAILED
The macro GSL_ERROR_VAL is defined as:
112 #define GSL_ERROR_VAL(reason, gsl_errno, value) \
113 do { \
114 gsl_error (reason, __FILE__, __LINE__, gsl_errno) ; \
115 return value ; \
116 } while (0)
Since the error handler is turned off, the gsl_error() call in the macro
does nothing and your GSL_ERANGE flag is lost. However, the
multimin_fminimizer_iterate() should still return an error code when it
gets the GSL_NAN so can you check what code is being returned?
On 02/07/2014 03:29 PM, Leek, Jim wrote:
Hi, I'm pretty new to GSL, but I should've started using it earlier.
Anyway, I've got a case where I'm doing a simple 2D optimization with
gsl_multimin_fminimizer_nmsimplex2 . One of the error conditions is that the
optimizer might stray out of the valid range. So, for that case I put in this
error in the 2D function:
if(v1 < vmin || v1 > vmax ||
v2 < vmin || v2 > vmax) {
GSL_ERROR_VAL("Optimization has spread outsize the bounds",
GSL_ERANGE, GSL_NAN);
}
This part seems to work, if I have the default error handler on, the program
crashes out with the proper error. But in my case this is actually a
recoverable error, I want to be able to handle it. So, I turn off the error
handler: gsl_set_error_handler_off();
Then I have this in the iteration loop:
do {
status = gsl_multimin_fminimizer_iterate(s);
if (status)
break;
....[snip]....
}
while (status == GSL_CONTINUE && iter < 1000);
if(status != GSL_SUCCESS) {
//If we slid out of range, just skip this optimization, it's out of
bounds.
if(status == GSL_ERANGE) {
return 0;
} else {
exit(status);
}
}
The check against GSL_ERANGE doesn't work, because the status returned turns
out to be GSL_EFAILED. So, no matter how I fail, I get the same error code
GSL_EFAILED. I think it's due to this line in multimin/simplex2.c :
line 522:
if (status != GSL_SUCCESS)
{
GSL_ERROR ("contraction failed", GSL_EFAILED);
}
So, simplex2 just eats my error code. This seems like a bug to me. Is this
intentional? It doesn't seem hard to fix.
Note, I'm using gsl 1.13 because that's what's installed on my machine, but
simplex2.c in gsl 1.16 is exactly the same file, so I don't think this
behaviour has changed.
Thanks,
Jim