[Bug-gsl] [bug #41527] Change/add multimin functions to return error codes

[Patrick Alken]

URL:
  <http://savannah.gnu.org/bugs/?41527>

                 Summary: Change/add multimin functions to return error codes
                 Project: GNU Scientific Library
            Submitted by: psa
            Submitted on: Sun 09 Feb 2014 05:35:26 PM GMT
                Category: None
                Severity: 3 - Normal
        Operating System: 
                  Status: None
             Assigned to: None
             Open/Closed: Open
                 Release: 
         Discussion Lock: Any

    _______________________________________________________

Details:

See following email thread from help-gsl:

Hello,

yes, it is a bad design originating from the early years. Multimin 
should be changed to use error codes as return values. And add an option 
for constrained optimization.

BTW, you might also consider using an additional cost function to steer 
clear of illegal values.

BR,
Tuomo

On 02/08/2014 04:29 AM, Patrick Alken wrote:
> I'm not sure why the multimin functions were set up that way (to return
> nan on errors instead of an error code). The multifit framework returns
> error codes, so there's something inconsistent there.
>
> Maybe Brian or Tuomo could weigh in since they appear to have written
> that code.
>
> In any case, for your problem you could look for the GSL_EFAILED return
> value and assume that problem originated in your function. The only
> other option I see is to set a global variable in your function.
>
> On 02/07/2014 04:43 PM, Leek, Jim wrote:
>> 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
>> ________________________________________

>>
>> 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.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?41527>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/