[SciPy-Dev] improvements of optimize package

Denis Laxalde denis.laxalde@mcgill...
Mon Sep 19 08:03:07 CDT 2011


Christopher Jordan-Squire wrote:
> Is there a reason to give two interfaces for constrained and
> unconstrained optimization instead of combining them somehow?

Not really. I thought that this minimal separation would lead to simpler
functions from a user perspective (i.e. less parameters/options to
consider for unconstrained minimization as compared to constrained
minimization, less doc to read, etc.) Yet, I don't mind implementing a
common function instead if you (and others) think it's better. Any
other opinions on this question?

> Why not include leastsq with the unconstrained optimization methods
> for the unconstrained optimization interface?

I think the main reason is that, in leastsq, the objective function
returns an array whereas in other methods it returns a scalar. This has
been discussed to some extent in the original thread [1]. The purpose
of leastsq is to solve a nonlinear least square problem so one might be
confused to have to look for it in the 'minimize' function. In some
respect, it is also close to root finding algorithms (and is often used
in place of the latter when singularities of the Jacobian occur in
particular). For this reason, I think leastsq should remain separate.
Yet, it should be possible to add it as a method in the unconstrained
optimization interface. I'll mention this on the proposal.

> Why not put anneal in with the unconstrained optimization interface?
> You could include in the interface the possibility of returning a
> dictionary of solver specific outputs.

That should be doable. I'll update the proposal accordingly.
What about brute?

> Bound constrained optimization should be associated with constrained
> optimization, not unconstrained. Also, I think there's a typo in the
> multivariate solvers: 'newton\_krylov' should be 'newton_krylov'.

Ok.

-- 
Denis

 1: http://mail.scipy.org/pipermail/scipy-user/2011-September/030444.html


More information about the SciPy-Dev mailing list