[Scipy-tickets] [SciPy] #923: Adding new options to the optimize.fmin_l_bfgs_b procedure .

SciPy Trac scipy-tickets@scipy....
Sun Sep 16 15:23:34 CDT 2012


#923: Adding new options to the optimize.fmin_l_bfgs_b procedure .
-------------------------------------+--------------------------------------
 Reporter:  gilles.rochefort         |       Owner:  somebody    
     Type:  enhancement              |      Status:  needs_review
 Priority:  normal                   |   Milestone:  0.12.0      
Component:  scipy.optimize           |     Version:  devel       
 Keywords:  optimize, fmin_l_bfgs_b  |  
-------------------------------------+--------------------------------------
Changes (by dlaxalde):

 * cc: dlaxalde (added)
  * milestone:  Unscheduled => 0.12.0


Comment:

 Replying to [ticket:923 gilles.rochefort]:
 > - Removed internal logging made from fortran code (as it always seems to
 failed) and get bored with''' iterate.dat''' file. Logging informations
 are now be done with '''pure python code'''.

 The Fortran output is rather comprehensive and might be useful for some
 people,
 so I'm not comfortable bypassing it completely. Also, logging to
 iterate.dat actually works, it is just re-written upon each iteration;
 maybe it's not the most elegant way to do this but, again, some people
 might use it and it doesn't harm in
 general.

 > - '''Adding a new stopping rule''' based on maximum iterations (maxiter)
 because maximum function evaluations don't always sound right (just think
 that an internal linesearch procedure also contribute to increase the
 number of function evaluations )

 I think the current stopping criterion (maximum function evaluations) is
 correct since, as far as I can tell, the internal L-BFGS-B routine does
 not call the function nor its gradient (only there value at the current
 iterate are passed), so the number of function evaluations equals the
 number of iterations.

 > - '''Adding a callback mecanism''', which allows to monitor solution,
 criterion, and gradient at current iteration.

 I agree that this would be useful. Yet, your proposal differs from
 existing callback mechanism in the optimize module, where the callback
 function usually accepts only the unknown vector. I'm made a
 [https://github.com/scipy/scipy/pull/317 pull request] for this tough.

-- 
Ticket URL: <http://projects.scipy.org/scipy/ticket/923#comment:2>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.


More information about the Scipy-tickets mailing list