Re: multimin question

[Fabrice Rossi <rossi at ufrmd dot dauphine dot fr>]

Dave Morrison wrote:
> 
> Hi,
> 
> I've been exploring the `multimin' parts of GSL and I've run into
> something I don't understand.  I recrafted the guts of multimin/test.c
> to minimize a simple paraboloid:
> 
> f = (x - 0.5)^2 + (y + 0.75)^2
> 
> So far, so good - you get an answer for the location of the minimum
> you'd expect: f(0.5, -0.75) ~ 0.0.  Also, the determination of the
> location of the minimum is insensitive to the starting point and any
> of the other parameters I chose to tweak.  I added a constant to `f':
> 
> f = (x - 0.5)^2 + (y + 0.75)^2 + 1.0
> 
> and started getting errors like these:
> 
> gsl: ../../gsl/multimin/fdfminimizer.c:300: ERROR: function not
> continuous
> 
> or
> 
> gsl: ../../gsl/min/fsolver.c:140: ERROR: endpoints do not enclose a
> minimum
> 
> or sometimes I get the right answer.  It depends on the details of the
> starting guess for (x,y), the value of the constant, and the values I
> feed to `gsl_multimin_fdf_minimizer_bracket'.  I realize the multimin
> code is under development, but does this sound familiar to anyone?  Do
> the minimization algorithms require that f(x) = 0 at the minimum in
> order to work properly?  That doesn't seem to be the case for the 1D
> algos, but is it true of the multidim ones?  I can supply the exact
> code I'm using if anyone's interested.  Help or advice appreciated.
> 
> Cheers,
> Dave

I've reproduced the bug. Basically, the problem comes from a stopping
condition (based on the norm of the gradient) that seems to be too strong in
my test code. If you increase the value (EPSABS, line 14 of test.c), the
problem should vanish. 

But I still don't understand exactly what is going on. The ERROR you obtain
(endpoints do not enclose a
 minimum) should not happen. In my bracketing code, the only way to obtain a
GSL_SUCCESS is to have endpoints that do enclose a minimum. I've checked this
(lines 46 to 52 of bracketing.c in the min directory), it's ok. 

I've tried to recompile bracketing.c with gcc -O1 rather than gcc -O1 and
suddenly the bug vanishes... (that is, the error handling code of test.c is
ok). I suspect there is something strange happening during the optimization,
because it seems that in bracketing.c, f_center>f_left, whereas when the
values in *f_lower and *f_minimum are equal... (when compiled under -O2). I've
tried different approaches such as printing (*f_lower>*f_minimum) just before
the return (line 52) and everything seem to agree on the fact that
(*f_lower>*f_minimum)!=(f_left>f_center).

This is really beyond my understanding of compilers and of ieee floating point
representation... I guess it might be related to the fact that registers store
floating with a higher precision than requested by ieee. Anyway, I don't know
what to do and I really need help on this point.

Fabrice Rossi