[SciPy-Dev] curve_fit() should require initial values for parameters

[Ralf Gommers]

On Thu, Jan 31, 2019 at 6:30 AM Matt Newville <newville at cars.uchicago.edu>
wrote:

>
>
> On Wed, Jan 30, 2019 at 2:26 PM Stefan van der Walt <stefanv at berkeley.edu>
> wrote:
>
>> On Wed, 30 Jan 2019 14:27:29 -0500, josef.pktd at gmail.com wrote:
>> > (I'm strongly in favor of trying "defaults" first, and if that doesn't
>> > work, then dig into or debug likely candidates. in loose analogy of test
>> > driven development instead of up-front design.)
>>
>> It seems unlikely that we will reach full agreement in this thread,
>> given the differing experiences and philosophies at play.  But, that's
>> probably OK if we can all agree to modify the documentation to be clearer
>> about the risks of the preset values for p0, how to select better
>> values, and how to handle failure modes.
>>
>> This won't 100% address Matt's concerns, but it will go a long way to
>> keeping users out of trouble, without having to make breaking changes to
>> the API.
>>
>> What do you think?
>>
>>
> Well, I'm not sure that agreement here should be the sole driver for what
> scipy developers do.  There will be disagreements in design philosophy, and
> someone needs to be willing and able to make decisions in such situations.
>  I do not know who is making such decisions or reviewing changes in
> `scipy.optimize`, but it appears to me that this has suffered for awhile,
> leaving conceptual, interface, and organizational messes.  I thought I
> would try to help by cleaning up one of the most egregious and simplest of
> these.
>
> The documentation for `curve_fit` does currrently state that `p0=None` is
> converted to `np.ones(n_variables)`.  It appears that some view this as
> sufficient and that these folks view some automated assignment of initial
> values is useful, even while acknowledging that it cannot be correct in
> general.
>
> The argument for requiring initial values might be summarized as "initial
> values are actually required".
> The argument against might be summarized as "we don't want to change the
> current behavior".
>
> Anyway, I am perfectly willing to lose this argument (I do not use
> `curve_fit` myself, and do not feel compelled to support its use), and the
> decision is not mine to make.  I do hope someone sensible is making these
> decisions.
>

To answer this "who makes the decisions" question: we usually try to get
consensus on any decision. Preferably by everyone who speaks up, otherwise
by all the core developers. If that doesn't happen (not often), then in
most cases people step out of the discussion and leave the decision to the
one or two core devs who worked in that area most. This discussion is a
rare example of there being two sides of the argument, both having merit,
and it's not really converging. The final decision options are:
1. The SciPy BDFL (Pauli) makes the final decision.
2. We can't get to an agreement and the BDFL doesn't decide, so the status
quo wins.

For now we should go ahead with improving the docs (Stefan's suggestions),
and then if Pauli wants to make a decision that would be great. Otherwise
we'll stick with just the doc improvements.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190201/9b084a68/attachment.html>