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

[Andras Deak]

One reason why I think this has become a surprisingly controversial
point is that on one hand curve_fit is a convenience function and it
works in a lot of cases as-is (and breaking APIs is difficult), but on
the other hand the guesswork involved in the default p0 choice goes
against "in the face of ambiguity, refuse the temptation to guess" of
native python. There are probably plenty of other cases where scipy
makes pragmatic choices which might otherwise seem "unpythonic", and
in case of such a high-level front-end I believe we're better off with
the current API, given that the documentation is made clear enough
when it comes to dangers of not passing a p0. But I can see why this
arbitrary choice for an important input parameter can be seen as a
problem.

András

On Wed, Jan 30, 2019 at 9:39 PM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
> For SO questions, 1st one agreed, 2nd one look at the given values. 3rd one have a look at the first line and also the comments. That's actually a counter argument.
>
> > That is certainly not the case. It is impossible to do so generally for every arbitrary nonconvex problem, which is why we can't automate it, but there are tons of problems where one has a reasonable idea from priors, examining the plotted data, or heuristic algorithms (e.g. finding the peak location and amplitude with a peak finder).
>
> Yes exactly my point. If you have a better idea put it in. p0 is not going to reject your guess but insist on 1.s. But I can give you easily tons of problems you can not give a proper guess. That is simply impossible because that defeats the purpose of why we use this tool.
>
>
>
>
>
> On Wed, Jan 30, 2019 at 9:25 PM Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Wed, Jan 30, 2019 at 10:48 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>>>
>>> I am a frequent user of this function. I am also occasionally teaching control theory and I use this also professionally, I provided a proper use case as a "user". You already admitted that you don't use it. So excuse me when I say that I have more experience than you about this function API (please read this twice; function API not the underlying theory). How can I even provide evidence on this completely subjective matter? Here is all the issues related to curve_fit
>>>
>>> https://github.com/scipy/scipy/search?q=curve_fit&type=Issues
>>>
>>> As far as I know there was no complaint so far.
>>
>>
>> StackOverflow is likely a better place to look for evidence:
>>
>> https://stackoverflow.com/questions/27097957/my-use-of-scipy-curve-fit-does-not-seem-to-work-well
>> https://stackoverflow.com/questions/23828226/scipy-curve-fit-does-not-seem-to-change-the-initial-parameters
>> https://stackoverflow.com/questions/53509550/error-in-scipy-curve-fit-for-more-than-two-parameters
>>
>>>
>>> Hence that means it is really not that big of a deal that would grant such tone. I don't know what to add other than what I already provided. You cannot make educated guesses about initial points on nonconvex searches. As you mentioned, we are as blind as np.ones(n) choice.
>>
>>
>> That is certainly not the case. It is impossible to do so generally for every arbitrary nonconvex problem, which is why we can't automate it, but there are tons of problems where one has a reasonable idea from priors, examining the plotted data, or heuristic algorithms (e.g. finding the peak location and amplitude with a peak finder).
>>
>> --
>> Robert Kern
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev