[Numpy-discussion] Speeding up numarray -- questions on its design

[konrad.hinsen at laposte.net]

On 19.01.2005, at 02:56, Perry Greenfield wrote:

> It distresses me to be accused of false advertising. We were pretty
> up front at the beginning of the process of writing numarray that the

It's not you, or the numarray team in general, that is being accused.  
Actually I doubt that any single person is responsible for the current  
state of misinformation. Those are the wonders of the OpenSource world.  
I saw Travis' post more as a request for clarification than an  
accusation against anyone in particular. As you describe very well,  
there is a gap between past intents and what has actually happened.

> concern about that), but it wasn't at all clear what the consensus
> was regarding how much it could change and be acceptable. (I recall

It's probably still not clear. Perhaps there is no consensus at all.

> The current situation is far from ideal (Paul called it "insane"
> at scipy if you prefer more colorful language). What we have are
> two camps that cannot afford to give up the capabilities that are
> unique to each version. But with most of the C-API compatable, and
> a way of coding most libraries (except for Ufuncs) to be compatible
> with both, we certainly can improve the situation.

I am not sure that compatibility is really the main issue. In the  
typical scientific computing installation, NumPy and numarray are  
building blocks. Some people use them without even being aware of them,  
indirectly through other libraries.

In a building-block world, two bricks should be either equivalent or be  
able to coexist. The original intention was to make NumPy and numarray  
equivalent, but this is not what they are at the moment. But they do  
not coexist very well either. While it is easy to install both of them,  
every library that builds on them uses one or the other (and to make it  
worse, it is not always easy to figure out which one is used if both  
are available). Sooner or later, anyone who uses multiple libraries  
that are array clients is going to have a compatibility issue, which  
will probably be hard to understand because both sides' arrays look so  
very similar.

Konrad.
--
------------------------------------------------------------------------ 
-------
Konrad Hinsen
Laboratoire Leon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: hinsen at llb.saclay.cea.fr
------------------------------------------------------------------------ 
-------