[SciPy-User] scipy.optimize named argument inconsistency

[Skipper Seabold]

On Sat, Sep 3, 2011 at 11:58 AM, Christopher Jordan-Squire
<cjordan1 at uw.edu> wrote:
> On Sat, Sep 3, 2011 at 11:42 AM, Skipper Seabold <jsseabold at gmail.com> wrote:
>> On Fri, Sep 2, 2011 at 10:31 AM, Denis Laxalde <denis.laxalde at mcgill.ca> 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 <joonpyro at 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. Also, 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'.
>>>
>>> If you still believe (as I do) that consistency of optimize
>>> functions should be improved, I can work on it. Let me know.
>>
>
> I'm also a fan of more consistent names. But with the caveat that I'm
> not currently using the optimization library for any major code, and I
> haven't looked around in the scipy.optimize code base a lot. So my
> opinion isn't particularly well-informed.
>
>>
>>
>> +1.
>>
>> I'd like to see the input and outputs streamlined as much as possible.
>> It would also be nice to have a convenience wrapper around all the
>> optimizers so that you can use them with one function. You'll have to
>> deprecate the old signatures though.
>>
>
> You mean just a generic function, where you can specify the solver
> method and the relevant inputs using the newly unified names?
>
> Sounds good to me. I'm not a fan that the generic fmin function is a
> nelder-mead algorithm. Nelder-mead has its place, but I don't think it
> should be given the basic, default looking name.
>

Yeah, something like R stats optim would make some of our code nicer.

http://stat.ethz.ch/R-manual/R-devel/library/stats/html/optim.html

Skipper