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

[Travis E. Oliphant]

Charles R Harris wrote:
>
> 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.
An intern did some work here last summer (and I did some work two 
summers ago).   Last summer's work never got integrated.   The goal is 
to unify and expand the interface to interp1d and interp2d and interpnd 
--- to allow for future improvement while improving the API as well as a 
few of the algorithms.   Basically, interpolate is one thing we teach 
quite a bit and it's a little embarrassing every time we teach it.    
>
> 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.
I'm very happy to change the name and/or the algorithm to improve the 
generality / speed.     Anything you have would be welcome.     Perhaps 
other people have a different perspective, but my perspective of the 
trunk is that it is not a release and so changes to new functionality in 
the trunk can be made with no concern of "backward-compatibility" until 
a release is made.  

Given the review tools I've seen.  My perspective on the best way to 
review is to look at changes to the trunk and just make the changes that 
you see as needed, or if it's not clear to you how to make the changes, 
you can put comments in the code about what you would like to see done 
and then perhaps somebody else can figure out how to make that change.    

In that process, we should all play nicely with each other and respect 
each other's opinions.  If an occasional point can't be resolved between 
the interested parties because of basically differences of opinion, then 
we can:  1) vote on the list and if that doesn't clearly resolve the 
question, 2) the steering committee votes and makes a decision.     
That's my perspective on how changes are made.  

-Travis