[SciPy-User] Least-squares fittings with bounds: why is scipy not up to the task?

josef.pktd@gmai... josef.pktd@gmai...
Fri Mar 9 06:12:09 CST 2012


On Fri, Mar 9, 2012 at 6:04 AM, Pauli Virtanen <pav@iki.fi> wrote:
> Hi,
>
> 09.03.2012 07:20, william ratcliff kirjoitti:
> [clip]
>> We also used the IDL version of  mpfit--in moving to python, I looked
>> for an analogue and found mpfit.py that at the time, relied on Numeric.
>>   I made a port to numpy and found Sergei Koposov had made a similar
>> port (http://code.google.com/p/astrolibpy/wiki/AstrolibpyContents) in
>> addition to fixing some bugs in the original and adding extensions.   I
>> talked with all of the stakeholders to receive licensing permission for
>> inclusion into scipy.   However, there were questions about the coding
>> style, and it never made it in.  (I'm happy to see the lmfit project on
>> github)
>
> Sorry, I completely forgot you had already done work for inclusion of
> mpfit, and I guess it was my reply that halted it:
>
>    http://mail.scipy.org/pipermail/scipy-dev/2009-May/011947.html
>
> My intent here was honestly not to be a total API zealot and say that
> *everything* needs to be fixed before checkin --- just that errors
> should raise exceptions, and some minor stylistic cleanup should be made
> --- the rest could be cleaned up later. Though, I can understand that a
> long laundry list of things to correct is not the nicest first response
> to code contributions.
>
> There's also a second issue here, which is more organizational --- since
> there was no procedure for the contributions, I lost track of where this
> work was progressing, and eventually forgot about it. This is where
> Github's pull requests improve the situation by a large amount. In
> principle Trac could serve the same role, but in practice it turns out
> to work somewhat less well.
>
> [clip]
>> Sorry that this is a bit disorganized, but the TL;DR is that I think
>> scipy could do more to make it easier for people to contribute... I
>> understand the need to have maintainable code in a large project, but in
>> many cases, having a less than perfect implementation (with tests) would
>> be better than having no implementation... Also, what may be easy for us,
>> may not be easy to many users of scipy, so having convenience methods is
>> worthwhile...
>
> The fine line to walk here is that there must be some quality control
> for code contributions, to avoid ending up with a set of routines that
> are awkward to use or don't work as promised (except around the research
> problem for which it was first written). The point in doing as much as
> possible before accepting contributions is that if this is left for
> later, the contributor may be MIA and there's nobody around who
> understands the piece of code well, and you're committed to a clunky API
> which you cannot easily change anymore if there has been a release in
> between. The flip side is of course that the barrier to contributions is
> higher, and it should not be made too high.

taking anneal as an example

None of the scipy "maintainers" knew the background for simulated annealing
The function in scipy has several problems, and it might take some
time for someone that understands this to make it work better.

The proposed patch for bounds, *replaced* the bounds on the updating
step with bounds on the parameters instead of adding an additional
functionality.

http://projects.scipy.org/scipy/ticket/1126
http://projects.scipy.org/scipy/ticket/875
http://article.gmane.org/gmane.comp.python.scientific.devel/10398

I didn't and don't think just changing the behavior was an appropriate patch.

Essentially, maintenance for global optimizers in scipy is MIA because
of the lack of someone (?) who can evaluate it and convert a patch
into a tested improvement of the code.

The advantage of a developers' own tools or utilities functions is
that the developer can do as much testing and quality control as (s)he
feels like or as much as is necessary for a specific use case.
For inclusion in scipy the quality control should be higher, in my opinion.

One advantage of scipy-central and a commenting system would be that
code will get user testing and feedback, so it's easier to evaluate
for inclusion in scipy whether the code works as promised, and is
useful to a wider audience.


scipy is missing linear programming, and quadratic programming in the
scipy.optimize, and there is no work-around. Both are "must-haves", I
think.

Josef

>
> The scipy-central.org is a good solution for just sharing research code
> with minimum hassle, and definitely could use more advertisement.
>
>        Pauli
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user


More information about the SciPy-User mailing list