[SciPy-User] scipy.optimize named argument inconsistency
Sun Sep 4 19:44:27 CDT 2011
On Friday, September 2, 2011 1:31:46 PM UTC-5, Denis Laxalde wrote:
> (I'm resurrecting an old post.)
> On Thu, 27 Jan 2011 18:54:39 +0800, Ralf Gommers wrote:
> > On Wed, Jan 26, 2011 at 12:41 AM, Joon Ro <joon...@gmail.com> wrote:
> > > I just found that for some functions such as fmin_bfgs, the argument
> > > for the objective function to be minimized is f, and for others such as
> > > fmin, it is func.
> > > I was wondering if this was intended, because I think it would be
> better to
> > > have consistent argument names across those functions.
> > >
> > It's unlikely that that was intentional. A patch would be welcome. "func"
> > looks better to me than "f" or "F".
> There are still several inconsistencies in input or output of functions
> in the optimize package. For instance, for input parameters the Jacobian
> is sometimes name 'fprime' or 'Dfun', tolerances can be 'xtol' or
> 'x_tol', etc. Outputs might be returned in a different order, e.g.,
> fsolve returns 'x, infodict, ier, mesg' whereas leastsq returns 'x,
> cov_x, infodict, mesg, ier'. Some functions make use of the infodict
> output whereas some return the same data individually. etc.
> If you still believe (as I do) that consistency of optimize
> functions should be improved, I can work on it. Let me know
I would add that the call signatures and return values for the user-supplied
function to minimize should be made consistent too. Currently, some
functions (leastsq) requires the return value to be an array, while others
(anneal and fmin_l_bfgs_b) require a scalar (sum-of-squares of residual).
That seems like a serious impediment to changing algorithms.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-User