[SciPy-User] Suggest moving curve_fit from minpack to top level

Robert Kern robert.kern@gmail....
Wed Feb 24 09:34:48 CST 2010

On Wed, Feb 24, 2010 at 08:48,  <josef.pktd@gmail.com> wrote:

> curve_fit doesn't really fit into scipy.optimize next to all the low
> level optimizers.
> Given the recent discussion, I think it would fit better in
> scipy.interpolate which could be extended to interpolate and fitting
> to noisy data, e.g. rbf, least squares splines.

Heh. This is precisely why scipy.odr is in scipy.odr. When I asked
where it should go, I got three responses and four opinions.
scipy.optimize and scipy.stats are both plausible places for these
routines; scipy.interpolate is plausible if you squint, but is not
really in my opinion. I would like to keep scipy.interpolate for real
interpolation methods. If those interpolation methods also have a
closely related mode for fitting noisy data, so be it, but we
shouldn't expand the scope to include all fitting methods that aren't
interpolation. Similarly, curve_fit() and leastsq() are really just
small wrappers around the underlying minimizers that do the heavy
lifting, so they ended up in scipy.optimize.

It might be time for a new top-level package scipy.fitting that brings
together all of the noisy fitting solutions and provides a nice place
for new code like Jonathan Stickel's. However, I would only want to do
that if we were providing something else along with it, like unifying
the interfaces or providing generic cross-validation routines that
would work with any fitter that had the right interface, etc. I think
that moving things around just to have a better organization is a
waste of time and is not justified by the costs of deprecating working
code and invalidating umpteen docs, tutorials, archived emails, blog
posts, Stack Overflow answers that are floating out there, being all
Googleable as outdated documentation is wont to be.

Ultimately, I think that the organization of functions into packages
is much less important than having quality documentation that answers
users' "How do I ...?" questions. I know it's much easier to move a
function into a new package than it is to write good docs, but it
doesn't solve the real problem.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco

More information about the SciPy-User mailing list