[Numpy-discussion] Time for beta1 of NumPy 1.0

[Jon Wright]

Travis Oliphant wrote:

>I hope he doesn't mean the rumors about an array object in Python 
>itself.  Let me be the first to assure everyone that rumors of a 
>"capable" array object in Python have been greatly exaggerated.  I would 
>be thrilled if we could just get the "infra-structure" into Python so 
>that different extension modules could at least agree on an array 
>interface.   That is a far cry from fulfilling the needs of any current 
>Num user, however.
>  
>
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. If the new array object supports most of the interface of the 
current "array" module then it is already very capable for many tasks. 
It would be great if it also works with Jython (etc).

Bruce Southley wrote:

>1) Identify those "[s]econdary dependency" projects as Louis states
>(BioPython also comes to mind) and get them to convert.
>
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). 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". 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?

Seeing this on the mailing list:

>So far the vote is 8 for float, 1 for int.
>
... is yet another hint that I can remain with Numeric as a library, at 
least until numpy has a frozen interface/behaviour.

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. Some reading at http://ndevilla.free.fr/median/median/index.html
or even (eek!) numerical recipes indicates this is not good news. Not to 
single one routine out, I was also saddened to find both Numeric and 
numpy use double precision lapack routines for single precision 
arguments. A diff of numpy's linalg.py with Numeric's LinearAlgebra.py 
goes a long way to explaining why there is resistance to change from 
Numeric to numpy. The boilerplate changes and you only get "norm" (which 
I am suspicious about - vector 2 norms are in blas, some matrix 2 norms 
are in lapack/*lange.f and computing all singular values when you only 
want the biggest or smallest one is a surprising algorithmic choice). I 
realise it might sound like harsh criticism - but I don't see what numpy 
adds for number crunching over and above Numeric. Clearly there *is* a 
lot more in terms of python integration, but I really don't want to do 
number crunching with python itself ;-)

For numpy to really be better than Numeric I would like to find 
algorithm selections according to the array dimensions and type. 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?


Jon