[SciPy-dev] Scikits for optimization ?

[Matthieu Brucher]

2007/5/11, Michael McNeil Forbes <mforbes at physics.ubc.ca>:
>
> Hi Matthieu,
>
> I have been busy lately, but I have been thinking about optimization,
> especially the interface to optimizers and I think that the current
> optimization module could do with a lot of cleaning up, but I have
> not had time to flesh out a full proposal yet.  (I started to do this
> on the Trac Wiki but need to think this through more carefully).



I'm not a pro here, so I'll follow the proposal as soon as it is ready ;)


Basically, there is very little cohesion with the various optimizers:
> they just wrap underlying fortran routines.  The arguments do not
> even have the same name.  It would be nice to flesh out a consistent
> interface and way of dealing with the plethora of options.  Once a
> consistent interface is established, then it would be easier to
> include additional optimizers built out of modules.



That would be indeed a good idea, I have myself my own naming convention for
parameters (x0 or start_point ?, ...)


Once this is set up, I think it would be good to have this in SciPy
> itself rather than a scikit because optimization is a core scientific
> task, but perhaps a scikit is a good place to start (also, a scikit
> is the only option if any code has an incompatible licence).



While I agree that optimization must stay in scipy, my point of view is
similar to Matlab's : some simple, ready-to-go functions for optimization
(fmin, leastsqr, ...) in the core, and an additional toolbox with more
flexibility, ... Otherwise, it could turn into a mess ?

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070511/453cc159/attachment.html>