[SciPy-Dev] curve_fit() should require initial values for parameters
Ilhan Polat
ilhanpolat at gmail.com
Fri Jan 25 10:11:56 EST 2019
As I commented on the GitHub issue, we are not supposed to educate users
through keywords and default values in a passive manner. A clear "You need
to choose p0 wisely to use this tool" message would be enough to be warned.
On Fri, Jan 25, 2019 at 12:48 PM Christoph Deil <
deil.christoph at googlemail.com> wrote:
> Dear Matt, Joseph, all,
>
> Here’s my 2 cents.
>
> On 24. Jan 2019, at 17:26, josef.pktd at gmail.com wrote:
>
> IMO, a warning and better documentation would be more appropriate.
>
> https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.curve_fit.html
> does not show an example with starting values.
> curve_fit could issue a warning if p0 is not specified, or warn if
> convergence fails and p0 was not specified.
>
>
> I think a better docstring for curve_fit would be good, mentioning the
> importance of specifying p0 and that the default is ones.
> Also +1 to add a mention of lmfit from the scipy.optimize docs somewhere,
> recommending it to users as a high-level package that directly builds on
> scipy.optimise providing extra functionality and conveniences.
>
> -1 on making the change to require p0 to be passed, and starting a
> deprecation process to eventually give an error on this in a few years.
> There are cases and existing scripts that work just fine with the current
> default. IMO they should continue to work (even without warning) in scipy
> 1.x just like they do in the currently scipy 1.1.
>
>
> I think it should also be possible to improve the default starting values,
> e.g. if the function fails or if bounds are provided.
>
>
> -1 on adding complex logic and guessing and trying code for p0 to
> curve_fit.
> scipy.optimize is pretty low-level, adding this kind of “convenience”
> which is hard to explain and document and maintain seems a bit out of place
> to me.
> Also any change in how p0 is chosen likely will change results that come
> out for some use cases, so for the same reason mentioned above (stability
> within the scipy 1.x series) I’m -1 to change this.
>
> Christoph
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190125/d6945d70/attachment-0001.html>
More information about the SciPy-Dev
mailing list