[SciPy-User] scipy.optimize named argument inconsistency

josef.pktd@gmai... josef.pktd@gmai...
Mon Sep 5 08:23:41 CDT 2011


On Sun, Sep 4, 2011 at 8:44 PM, Matthew Newville
<matt.newville@gmail.com> wrote:
> Hi,
>
> On Friday, September 2, 2011 1:31:46 PM UTC-5, Denis Laxalde wrote:
>>
>> Hi,
>>
>> (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
>> > > name
>> > > 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
>
> Also +1.
>
> 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.

I don't see how that would be possible, since it's a difference in
algorithm, leastsq needs the values for individual observations (to
calculate Jacobian), the other ones don't care and only maximize an
objective function that could have arbitrary accumulation.

Otherwise I'm also +1.
It might be a bit messy during deprecation with double names, and
there remain different arguments depending on the algorithm, e.g.
constraints or not, and if constraints which kind, objective value and
derivative in one function or in two.

Josef

>
> --Matt Newville
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>


More information about the SciPy-User mailing list