Re: [Help-gsl] Doing multimin, but my error gets coverted to GSL_EFAILED

[Patrick Alken]

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