bug-gsl
[Top][All Lists]
Advanced

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

Re: [Bug-gsl] Fix bug in multimin/directional_minimize.c


From: Brian Gough
Subject: Re: [Bug-gsl] Fix bug in multimin/directional_minimize.c
Date: Wed, 07 Apr 2010 22:41:07 +0100
User-agent: Wanderlust/2.14.0 (Africa) Emacs/22.2 Mule/5.0 (SAKAKI)

At Fri, 12 Mar 2010 11:56:33 +0000,
Brian Gough wrote:
> At Fri, 5 Mar 2010 20:38:30 -0500 (EST),
> Gallego Bonet, Guillermo wrote:
> > I think it would be wise to replace, inside function
> > intermediate_point(), the condition
> > 
> > if (fb >= fa && stepb > 0.0)
> > 
> > by
> > 
> > if (fb >= fa && stepb > STEP_TOL)
> > 
> > where one could define the tolerance to be any value related to the
> > machine precision. I used
> > 
> > #define STEP_TOL 1e-7
> > 
> > I tested the Fletcher-Reeves and PR algorithms (
> > gsl_multimin_fdfminimizer_conjugate_fr(), ... ) to minimize an
> > expensive cost function in R^4 and I was surprised that the function
> > gsl_multimin_fdfminimizer_iterate() would take so long to return. I
> > found out it was because the line minimization routine was testing
> > many smaller and smaller steps (up to 10^-186 !!, which I believe is
> > totally unnecessary in any practical situation).
> 
> Thanks for the bug report.  I agree the test could be stricter -- I
> think the correct approach is to return when the step is small enough
> that it does not alter the trial vector.

I've committed a fix for this, the routines now return immediately
with GSL_ENOPROG as soon as the trial point does not change (within
machine precision).  Thanks for the bug report.

-- 
Brian Gough
(GSL Maintainer)

Network Theory Ltd,
Publishing the GSL Manual - http://www.network-theory.co.uk/gsl/manual/




reply via email to

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