[SciPy-dev] scipy.optimize

Ed Schofield schofield at ftw.at
Mon May 1 06:37:00 EDT 2006


On 28/04/2006, at 4:41 PM, Robert Cimrman wrote:

> Ed Schofield wrote:
>> Robert Cimrman wrote:
>>
>>> Yes, fmin_l_bfgs_b uses a wrapped fortran module, so I can think  
>>> only
>>> about rewriting its high-level logic (the main iteration loop?) in
>>> Python, using directly the fortran subroutines. But all functions in
>>> optimize.py could use the common interface without pain.
>>>
>>> The two main possibilities are:
>>> 1) call back each iteration (as I do in my fmin_sd) only
>>> 2) call back via wrap_function macro, so that function/gradient  
>>> calls
>>> e.g. in line search functions are not missed - the callback could  
>>> have
>>> one arg saying from where it was called, so that in  
>>> postporcessing you
>>> could plot e.g. just the data from main loop iterations.
>>>
>>> Now as I have written them down, I would vote for 2) in some form.
>>
>> Yes, (2) would be good :)
>
> OK, I am willing to do a prototype in the sandbox. Unfortunately I  
> will
> be available first after 9. May :(, so be patient.

Okay ;)

I've been thinking more about the callback functions, and I now think  
a context parameter might be unnecessary.  The reason is that the  
function and gradient (and perhaps Hessian) are provided by the user,  
and these can easily be written to perform any necessary logging or  
reliability analysis that should be performed each evaluation.  All  
that's missing is the ability to run code each iteration (excluding  
line searches).


>>
>> It looks like a good start.  I suggest you copy the whole  
>> scipy.optimize
>> package into the sandbox (e.g. as 'newoptimize') and check your  
>> code in
>> there...
>
> It's there and I removed dependencies on my other codes, so that  
> you can
> try it - run test_optimize.py, or try_log.py

Great.  I'll help you work on it when I get some time (in a few weeks).

-- Ed




More information about the SciPy-Dev mailing list