Re: [SciPy-Dev] SciPy-Dev Digest, Vol 128, Issue 5
Hi William, Sturla, Josef, All Message: 2
Date: Tue, 17 Jun 2014 09:32:44 -0400 From: william ratcliff <william.ratcliff@gmail.com> Subject: Re: [SciPy-Dev] Levenberg-Marquardt Implementation To: SciPy Developers List <scipy-dev@scipy.org> Message-ID: < CAFt3ydvxgC3KVofi0v4U8-pCmfgdo3bBhJfhrkne7ZLkWcTVfQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
This issue does seem to come up regularly. There is a BSD licensed version: https://github.com/newville/lmfit-py
For mpfit.py, at one point, I got license permissions for scipy from the original authors, but no one wanted to include it. Has that changed? I haven't followed the issue since 2012.
Best, William
On Tue, Apr 1, 2014 at 7:57 AM, Johann cohen-tanugi < johann.cohentanugi@gmail.com> wrote:
FWIW I came across a python LM implementation of the minpack LM routine in https://code.google.com/p/astrolibpy/source/browse/mpfit/mpfit.py The license is GPLv3 though. Johann
On Tue, Feb 25, 2014 at 7:25 PM, Pauli Virtanen <pav@iki.fi> wrote:
25.02.2014 17:45, Benny Malengier kirjoitti:
This is present already, See
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.leastsq.h...
which wraps: http://www.math.utah.edu/software/minpack/minpack /lmder.html
The current leastsq implementation does not support sparse Jacobians or constraints.
MINPACK does dense QR factorizations, and this approach doesn't work well for problems where the number of variables is too big. This was one of our the GSoC topic ideas [1] --- if you have suggestions on how to improve these, please speak up.
[1] https://github.com/scipy/scipy/wiki/GSoC-project-ideas
-- Pauli Virtanen
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Matt Newville <newville@cars.uchicago.edu> wrote:
I don't disagree that scipy could use more pure optimizers, but I also think that striving for a more consistent and elegant interface to these would be very helpful. With the notable exception of the relatively recent unification of the scaler minimizers with minimize(), it seems that many of the existing methods are fairly bare-bones wrappings of underlying C or Fortran code. Of course, having such wrapping is critically important, but I think there is a need for a higher level interface as well.
The raison d'etre for SciPy is "nice to use". So clearly simple and intuitive high-level interfaces are needed. If we only cared about speed we should all be coding in Fortran 77. Personally I am willing to scrifice a lot of speed for a nice high-level interface. Currently my main interest in SciPy's LM is the underlying solver, though. It's a very old Fortran code that even supplies its own linear algebra solvers because it was written before LAPACK. It's not very nice on modern computers, for various reasons. Sturla
participants (2)
-
Matt Newville -
Sturla Molden