<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 24, 2019 at 1:46 PM Stefan van der Walt <<a href="mailto:stefanv@berkeley.edu">stefanv@berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Josef,<br>
<br>
On Thu, 24 Jan 2019 11:26:09 -0500, <a href="mailto:josef.pktd@gmail.com" target="_blank">josef.pktd@gmail.com</a> wrote:<br>
> I think making initial values compulsory is too much of a break with<br>
> tradition.<br>
> IMO, a warning and better documentation would be more appropriate.<br>
> <a href="https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.curve_fit.html" rel="noreferrer" target="_blank">https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.curve_fit.html</a><br>
> does not show an example with starting values.<br>
> curve_fit could issue a warning if p0 is not specified, or warn if<br>
> convergence fails and p0 was not specified.<br>
<br>
Isn't the greater danger that convergence succeeds, with p0 unspecified,<br>
and the resulting model not being at all what the user had in mind?<br></blockquote><div><br></div><div>Unless the optimization problem is globally convex, the user always needs to check the results.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I think it should also be possible to improve the default starting values,<br>
> e.g. if the function fails or if bounds are provided.<br>
<br>
This is the type of magic I hope we can avoid.  Having different<br>
execution paths based on some vaguely defined notion of perceived<br>
failure seems dangerous at best.<br></blockquote><div><br></div><div>I there is no guarantee for a global optimum, it's still what either the program or the user has to do.</div><div><br></div><div>E.g. for statsmodels (very rough guess on numbers)</div><div>90% of the cases work fine</div><div>10% of the cases the data is not appropriate, singular, ill conditioned or otherwise "not nice"</div><div>10% of the cases the optimizer has problems and does not converge.</div><div><br></div><div>In this last case either the program or the user needs to work more:</div><div>We can try different optimizers, e.g. start with nelder-mead before switching to a gradient optimizer.</div><div>Or, switch to global optimizer from scipy, if the underlying model is complex and might not be well behaved.</div><div>or pure man's global optimizer: try out many different random or semi-random starting values.</div><div>(and if all fails go back to the drawing board and try to find a parameterization that is better behaved.)</div><div><br></div><div>statsmodels is switching optimizers in some cases, but in most cases it is up to the user to change the optimizers after convergence failure.</div><div>However, we did select default optimizers by which scipy optimizer seems to work well for the various cases.</div><div>Stata is also switching optimizers in some cases, and AFAIR has in some cases and option to "try harder".</div><div>statsmodels is still missing an automatic "try harder" option, that automatically switches optimizers on convergence failure.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I'm not a user of curve_fit, but I guess there might be a strong selection<br>
> bias in use cases when helping out users that run into problems.<br>
<br>
I agree; and I think this can be accomplished by better documentation,<br>
helpful warnings, and assisting the user in choosing correct parameters.<br></blockquote><div><br></div><div>The main question for me is whether the warnings and improved documentation are enough, or whether curve_fit needs to force every user to specify the starting values.</div><div><br></div><div>i.e. I think</div><div>Try automatic first, and if that does not succeed, then the user has to think again, </div><div>is more convenient, than </div><div>"you have to think about your problem first, don't just hit the button".</div><div><br></div><div>Josef</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards,<br>
Stéfan<br>
_______________________________________________<br>
SciPy-Dev mailing list<br>
<a href="mailto:SciPy-Dev@python.org" target="_blank">SciPy-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/scipy-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/scipy-dev</a><br>
</blockquote></div></div>