[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Leek, Jim
Subject: Re: [Help-gsl] Doing multimin, but my error gets coverted to GSL_EFAILED
Date: Fri, 7 Feb 2014 23:43:37 +0000

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;
    if (status != GSL_SUCCESS) GSL_ERROR ("contraction failed", GSL_EFAILED);
In short, iterate gets the Nan, throws EBADFUNC, then gets EBADFUNC and throws 

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

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 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]