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

Stefan van der Walt stefanv at berkeley.edu
Wed Jan 23 23:41:43 EST 2019


Hi Matt,

On Wed, 23 Jan 2019 19:24:57 -0600, Matt Newville wrote:
> First, I apologize in advance if this sounds un-appreciative of the efforts
> made in scipy and scipy.optimize.

Nothing you said in your email sounds unappreciative to me, for what
it's worth.

> Unfortunately, faced with no initial parameter values, `curve_fit` silently
> chooses initial values.  It doesn't try to make an informed decision, it
> simply chooses '1.0', which can easily be so far off as to prevent a
> solution from being found. When this happens, `curve_fit` gives no
> information to the user of what the problem is.  Indeed it allows initial
> values to not be set, giving the impression that they are not important.
> This impression is wrong: initial values are always important. `curve_fit`
> is mistaken in having a default starting value.
> 
> I've made a Pull Request at https://github.com/scipy/scipy/pull/9701 to fix
> this misbehavior, so that `curve_fit()` requires starting values.  It was
> suggested there that this topic should be discussed here. I'm happy to do
> so.  It was suggested in the github Issue that forcing the user to give
> initial values was "annoying".  It was also suggested that a deprecation
> cycle would be required. I should say that I don't actually use
> `curve_fit()` myself, I'm just trying to help make this commonly used
> routine be completely wrong less often.

Thank you for highlighting this issue.  In general, magic is to be
avoided, where possible.  In this case, I would suggest:

1. For one or two releases, changing the function to warn when no default
   is specified. Then, turn that warning into an error, that
   also explains good rules of thumb for calculating initial values (and
   mentions the 'auto' method in #2 below).

2. Provide an easy mechanism to get sensible defaults.  I.e., allow
   specific values to be specified, but also allow estimation methods,
   such as 'auto' (just an example, this would probably be more specific)
   or 'ones' (to restore old behavior, and to prevent existing users
   from having to modify their code drastically).

Stéfan


More information about the SciPy-Dev mailing list