[SciPy-Dev] optimize.fmin_ncg bug

[Ralf Gommers]

There has been an intermittent test failure in scipy.optimize for a long
time, only on Windows:

======================================================================
ERROR: line-search Newton conjugate gradient optimization routine
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"C:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line
115, in test_ncg
    retall=False)
  File "C:\Python26\lib\site-packages\scipy\optimize\optimize.py", line
1096, in fmin_ncg
    alphak, fc, gc, old_fval = line_search_BFGS(f,xk,pk,gfk,old_fval)
  File "C:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 600,
in line_search_BFGS
    phi_a2 = f(*((xk+alpha2*pk,)+args))
  File "C:\Python26\lib\site-packages\scipy\optimize\optimize.py", line 103,
in function_wrapper
    return function(x, *args)
  File
"C:\Python26\lib\site-packages\scipy\optimize\tests\test_optimize.py", line
41, in func
    raise RuntimeError, "too many iterations in optimization routine"
RuntimeError: too many iterations in optimization routine

----------------------------------------------------------------------

I finally managed to track it down to line 1076 of optimize.py:
    if curv == 0.0:

This should be replaced with "if curv < eps:" with eps a suitably small
number. Now my question is, how small is suitably small? 1e-10 seems to
work, but maybe someone who known what the algorithm does can suggest a
number that's not just a wild guess.

Looking at the rest of optimize.py, there's quite a bit of comparing with
zero going on which doesn't look right. Sometimes even with a comment like
"maybe this slipped below machine precision". Comparing floating point
numbers with zero like that is just a bad idea and should be fixed.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100703/4396e5af/attachment.html>