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

[Pauli Virtanen]

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.

The scipy-central.org is a good solution for just sharing research code
with minimum hassle, and definitely could use more advertisement.

	Pauli