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

Pauli Virtanen pav@iki...
Fri Mar 9 12:47:20 CST 2012


Hi,

09.03.2012 17:51, william ratcliff kirjoitti:
[clip]
> In this particular case, what are the exact steps needed to get it into
> scipy?  Can they charge be listed as tickets somewhere so that others of
> us can help?  Can we document the process to make it easier the next
> time?  I realize everyone is busy, but if the barrier to contribution is
> lowered it will make life better in the long run.

In general, basically two ways for contributions:

1. A pull request via Github. We have a writeup here with various tips:

   http://docs.scipy.org/doc/numpy/dev/gitwash/development_workflow.html

   Just replace "Numpy" by "Scipy" everywhere.

2. File a ticket in the Trac: http://projects.scipy.org/scipy/

   Attach whetever you have (a patch, separate files) to the ticket,
   and tag it as "enhancement" and "needs_review".

That's about it.

    ***

However, to make it easier for someone to look at the work and verify it
works properly:

- Ensure your code is accompanied by tests that demonstrate it actually
  works as intended. You can look for examples how to write them in the
  Scipy source tree, in files named test_XXX.py

- Ensure the behavior of the public functions is documented in the
  docstrings.

- Prefer the Github way. Granted, there *is* a learning curve, but it
  saves work in the long run, and it is far less clunky to use.

- The more finished the contribution is, the less work it is to merge,
  and gets in faster.

If you get no response, shout on the scipy-devel mailing list. If
there's still no response, shout louder and start accusing people ;)

If the contribution is "controversial" --- duplicates existing
functionality, breaks backwards compatibility, is very specialized for a
particular research problem, relies on magic, etc. --- it's good to give
an argument why the stuff should be included, as otherwise the
motivation may be missed.

Specific to mpfit: this can be regarded as a "just another optimization
routine", and that doesn't seem too controversial to me. It would be
nicer to subsume the functionality to leastsq, though, but I don't see
anyone wanting to modify the MINPACK fortran code. Instead, perhaps this
could be addressed on the level of the unified optimization interface.

Cheers,
Pauli



More information about the SciPy-User mailing list