[SciPy-dev] The future of SciPy and its development infrastructure

[Charles R Harris]

On Wed, Feb 25, 2009 at 4:18 PM, Travis E. Oliphant
<oliphant at enthought.com>wrote:

>
> I've written a lot of response to various comments and I'd like to
> summarize and extend a few of my comments:
>
> 1)  We absolutely need to improve the quality of SciPy, and that does
> mean more tests, documentation, and reviews --- and most importantly
> faster releases.    Right now, a release happens when someone steps up
> to be a release manager and commits to making it happen.    I don't know
> how to promise that on a regular cycle with only volunteer effort.    I
> would love to have the resources to fund SciPy release management.
>
> 2)  I think we are doing a decent job of commits having tests and
> documentation.    We should continue to remind each other of the need
> for quality code in SciPy (and continue to clean up code that is there).
>
> 3) There are pieces of SciPy that need work (interpolate stands out most
> in my mind right now).    I have changes to the interpolate code that I
> have not yet committed because I was waiting for the release of 0.7 but
> I really want to commit.  Who is interested in reviewing this?  I'm
> happy to work with additional eyes, but my current workflow is "commit
> code I think is working along with some tests and docstrings", and then
> let review/improve happen on the trunk.    I don't really like having
> lots of branches checked out of a code-base in order to manage a
> different workflow.  I'm open to being educated about approaches that
> work better.
>

Interpolate stands out in my mind also, along with signal processing. Mostly
because last time I looked -- a long time ago -- they were pretty messy and
I haven't seen much work done on them since. I think in this case it would
be helpful if you summarized your intended changes and interfaces and gave a
short explanation of your motivation. By the time the code actually shows up
in SVN might be a little late.

I think a similar approach would have helped with curve_fit, not least since
I have found Gauss-Newton with numerical derivatives to out-perform
Levenburg-Marquardt by ~50x in some problems and give better answers. Then
there is the question of when to stop the iterations. Also, I couldn't see
if the function and data could be array valued, which can be handy in some
cases. For instance, I recently fit a case where the parameters moved a
large set of points around on a unit sphere in order to minimize the
distance to data points on the sphere. In this case the output of f was most
conveniently represented as an array of vectors. Mind, I don't mind the
function itself so much as giving it a name that implies more generality
than I think it has.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20090225/afb0629f/attachment.html>