[SciPy-dev] The future of SciPy and its development infrastructure
Charles R Harris
Wed Feb 25 18:03:26 CST 2009
On Wed, Feb 25, 2009 at 4:18 PM, Travis E. Oliphant
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Scipy-dev