[SciPy-User] scipy.optimize named argument inconsistency

josef.pktd at gmail.com josef.pktd at gmail.com
Tue Sep 6 10:16:27 EDT 2011


On Mon, Sep 5, 2011 at 2:36 PM, Matthew Newville
<matt.newville at gmail.com> wrote:
>
>
> On Monday, September 5, 2011 8:23:41 AM UTC-5, joep wrote:
>>
>> On Sun, Sep 4, 2011 at 8:44 PM, Matthew Newville
>> <matt.n... at 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 <joo... 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. 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.
>
> Well, I understand that this adds an implicit bias for least-squares, but
> if the algorithms receive an array from the user-function, taking
> (value*value).sum() might be preferred over raising an exception like
>     ValueError: setting an array element with a sequence

I'd rather have an exception, but maybe one that is more explicit.
leastsq is efficient for leastsquares problems. If I switch to fmin or
similar, it's usually because I have a different objective function,
and I want to have a reminder that I need to tell what my objective
function is (cut and paste errors are pretty common).

>
> which is apparently meant to be read as "change your function to return a
> scalar".  I don't see in the docs where it actually specifies what the user
> functions *should* return.
>
> I also agree with Charles' suggestion. Unraveling multi-dimensional arrays
> for leastsq (and others) would be convenient.

I'm not quite sure what that means.

I think there is a difference between low level wrappers for the
optimization algorithms (leastsq) and "convenience" functions like
curve_fit.

I'm in favor of standardizing names (original topic), but I don't
think it is useful to "enhance" general purpose optimizers with lot's
of problem specific features and increase the list of optional
arguments.

However, pull request for convenience function to accompany curve_fit
might be very welcome.

Josef
OT reply to Christoph Deil moved to
https://groups.google.com/group/pystatsmodels/topics

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



More information about the SciPy-User mailing list