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

Ilhan Polat ilhanpolat at gmail.com
Wed Jan 30 02:47:22 EST 2019


Sorry, I can't see this helps our users by forcing them entering values
that they have no idea about would educate them about nonconvexity of the
problem. This is properly documented in the argument docs and we can expand
it and if they don't read the docs we are done. My opinion is that we are
trying to solve a problem that doesn't exist.

On Wed, Jan 30, 2019 at 2:30 AM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On Tue, 29 Jan 2019 17:53:37 +0100, Ilhan Polat wrote:
> > > The problem I have with this is that there really is not an option to
> "try
> > automatic first".  There is "try `np.ones(n_variables)` first".   This,
> or
> > any other value, is really not a defensible choice for starting
> > values.  Starting
> > values always depend on the function used and the data being fit.
> >
> > Why not? 1.s are as good as any other choice.
>
> This entire thread is about why np.ones is not a good choice.  It is not
> as good as any other in any particular case, and is patently wrong for
> most problems.  Sure, each problem has its own "better" and "worse"
> initial values, so if you are trying to optimize over all possible
> cases, it may be as good a choice as any other.  But the question here
> is exactly about whether that is a sensible thing to do.  Matt argues
> that it is not, and I find his argument convincing.
>
> The current API leads the user to believe that, without specifying p0,
> they are likely to get a reasonable answer out.  We can help our users
> by signaling to them that this is simply not the case.
>
> Best regards,
> Stéfan
> _______________________________________________
> 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/20190130/fc7d79e6/attachment-0001.html>


More information about the SciPy-Dev mailing list