[SciPy-dev] adding mpfit to scipy optimize (Please respond)
Charles R Harris
charlesr.harris at gmail.com
Sat May 9 12:17:18 EDT 2009
On Sat, May 9, 2009 at 10:07 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:
>
>
> On Sat, May 9, 2009 at 9:55 AM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> Fri, 08 May 2009 16:09:35 -0400, william ratcliff wrote:
>>
>> > Hi! For a long time, there has been a standard package used by IDL
>> > users for fitting functions to data called MPFIT:
>> > http://cow.physics.wisc.edu/~craigm/idl/fitting.html<http://cow.physics.wisc.edu/%7Ecraigm/idl/fitting.html>
>> > <http://cow.physics.wisc.edu/%7Ecraigm/idl/fitting.html>
>> [clip]
>> > http://drop.io/mpfitdrop
>>
>> Nice!
>>
>> However, I see some points where the code could be improved for better
>> reusability and maintainability.
>>
>> If we lived in an ideal world with infinite time to polish everything,
>> I'd like to see all of the points below addressed before landing this to
>> Scipy. But since this would be lots of error-prone work, it's probably
>> best to try to reach some compromise.
>>
>> Given these constraints, I'd still like to see at least the coding style
>> and error handling fixed (which probably are not too difficult to
>> change), in addition to having better test coverage. The rest could come
>> later, even if we accrue yet more technical debt with this...
>>
>>
>> First, broad maintenance concerns:
>>
>> - We already have `leastsq` from MINPACK. Having two MINPACK-derived
>> least squares fitting routines is not good.
>>
>> So, I'd perhaps like to see the `leastsq` core part extracted out of
>> MPFIT, and the MPFIT interface implemented on top of it as a thin
>> wrapper, or the other way around.
>>
>> Maybe, if the modifications made on MINPACK are small, they can be
>> backported to the Fortran code and MPFIT can be reimplemented on top
>> of `leastsq`.
>>
>> Any thoughts on this?
>>
>> - What is the performance of the Python implementation as compared to the
>> Fortran code? For small data sets, the Python code is probably much
>> slower, but for large datasets is the performance is comparable?
>>
>> - Much of the code is Fortran written in Python: long routines,
>> goto-equivalents, 6-letter variable names.
>>
>> Good commenting offset this, though.
>>
>>
>> Then more specific points of refactoring:
>>
>> - The code implements QR factorization with column pivoting from scratch.
>>
>> Perhaps some of this could be replaced with suitable LAPACK routines,
>> or with stuff from scipy.linalg. (Cf. DGEQPF, DGEQP3)
>>
>> I'm not sure whether there's something suitable for qrsolve in LAPACK;
>> the triangular system solver could be replaced with DTRTRS.
>>
>> Anyway, it might be useful to refactor qrfac and qrsolve out of MPFIT;
>> there may be other applications when it's useful to be able to solve
>> ||(A + I lambda) x - b||_2 = min! efficiently for multiple different
>> `lambda` in sequence.
>>
>
> This looks like Levenberg-Marquardt. There is a version already in MINPACK.
>
Not exactly though, the version quoted depends on the column ordering of A.
That doesn't look right.
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090509/9b5301e8/attachment.html>
More information about the SciPy-Dev
mailing list