[Numpy-discussion] Time for beta1 of NumPy 1.0

[Travis Oliphant]

Jon,

Thanks for the great feedback.  You make some really good points.

>  
>
>Having {pointer + dimensions + strides + type} in the python core would 
>be an incredible step forward - this is far more important than changing 
>my python code to do functionally the same thing with numpy instead of 
>Numeric. 
>
Guido has always wanted consensus before putting things into Python.  We 
need to rally behind NumPy if we are going to get something of it's 
infrastructure into Python itself.

>As author of a (fairly obscure) secondary dependency package it is not 
>clear that this is right time to convert. I very much admire the 
>matplotlib approach of using Numerix and see this as a better solution 
>than switching (or indeed re-writing in java/c++ etc). 
>
I disagree with this approach.   It's fine for testing and for 
transition, but it is a headache long term.  You are basically 
supporting three packages.  The community is not large enough to do 
that.  I also think it leads people to consider adopting that approach 
instead of just switching.  I'm not particularly thrilled  with 
strategies that essentially promote the existence of three different 
packages.

>However, looking 
>into the matplotlib SVN I see:
>
>_image.cpp      2420      4 weeks      cmoad      applied Andrew Straw's 
>numpy patch
>numerix/_sp_imports.py      2478      2 weeks      teoliphant      Make 
>recent changes backward compatible with numpy 0.9.8
>numerix/linearalgebra/__init__.py      2474      2 weeks      teoliphant 
>     Fix import error for new numpy
>
>While I didn't look at either the code or the diff the comments clearly 
>read as: "DON'T SWITCH YET". 
>
I don't understand why you interpret it that way?   When I moved 
old-style names to numpy.oldnumeric for SVN numpy, I needed to make sure 
that matplotlib still works with numpy 0.9.8 (which has the old-style 
names in the main location). 

Why does this say "DON'T SWITCH"?  If anything it should tell you that 
we are conscious of trying to keep things working together and 
compatible with current releases of NumPy.

>Get the basearray into the python core and 
>for sure I will be using that, whatever it is called. I was tempted to 
>switch to numarray in the past because of the nd_image, but I don't see 
>that in numpy just yet?
>  
>
It is in SciPy where it belongs (you can also install it as a separate 
package).  It builds and runs on top of NumPy just fine.  In fact it was 
the predecessor to the now fully-capable-but-in-need-of-more-testing 
numarray C-API that is now in NumPy.

>I am very supportive of the work going on but have some technical 
>concerns about switching. To pick some examples, it appears that 
>numpy.lib.function_base.median makes a copy, sorts and picks the middle 
>element. 
>
I'm sure we need lots of improvements in the code-base.   This has 
always been true.  We rely on the ability of contributors which doesn't 
work well unless we have a lot of contributors which are hard to get 
unless we consolidate around a single array package. Please contribute a 
fix. 

>single one routine out, I was also saddened to find both Numeric and 
>numpy use double precision lapack routines for single precision 
>arguments. 
>
The point of numpy.linalg is to provide the functionality of Numeric not 
extend it.   This is because SciPy provides a much more capable linalg 
sub-package that works with single and double precision.   It sounds 
like you want SciPy.

>For numpy to really be better than Numeric I would like to find 
>algorithm selections according to the array dimensions and type. 
>
These are good suggestions but for SciPy.  The linear algebra in NumPy 
is just for getting your feet wet and having access to basic 
functionality. 

>Getting 
>the basearray type into the python core is the key - then it makes sense 
>to get the best of breed algorithms working as you can rely on the 
>basearray being around for many years to come.
>
>Please please please get basearray into the python core! How can we help 
>with that?
>  
>
There is a PEP in SVN (see the array interface link at 
http://numeric.scipy.org)  Karol Langner is a Google summer-of-code 
student working on it this summer.  I'm not sure how far he'll get, but 
I'm hopeful.

I could spend more time on it, if I had funding to do it, but right now 
I'm up against a wall.

Again, thanks for the feedback. 

Best,

-Travis