[Numpy-discussion] Status of Numeric

[Chris Barker]

Konrad Hinsen wrote:
>   My view is that any
> package that is upwards-compatible with Numeric (except for bug fixes 
> of course) should be called Numeric and distributed as such. Any 
> package that is intentionally incompatible with Numeric in some 
> important aspect should not be called Numeric.

I absolutely agree with this.

Travis Oliphant wrote:

 > 1) change the coercion model to reflect Numarray's choice and eliminate
 > the savespace crutch.
 > 2) Add indexing capability to Numeric arrays (similar to Numarray's)
 > 3) Improve the interaction between Numeric arrays and scalars.

These all look like backward in-compatable changes, so in that case, I 
vote for Sci-py-array, or whatever.

However, it also looks like these are all moving toward the Numarray 
API. Is this the case? That would be great, as then Numarray would just 
be dropped in if/when it is deemed up to the task. It also leaves the 
door open for some sort of automagic selection of which array to use for 
a given instance.

 > 4) Optimization:

Nothing wrong with that...as long as it's not premature!

> Numarray is making great progress and is quite usable for many 
> purposes.  An idea that was championed by some is that the Numeric code 
> base would stay static and be replaced entirely by Numarray.

> However, Numeric is currently used in a large installed base.  In 
> particular SciPy uses Numeric as its core array.  While no doubt 
> numarray arrays will be supported in the future, the speed of the less 
> bulky Numeric arrays and the typical case that we encounter in SciPy of 
> many, small arrays will make it difficult for people to abandon Numeric 
> entirely with it's comparatively light-weight arrays.

It was said that making Numarray more efficient with small arrays was a 
goal of the project...is it still? I'm still unclear on why Numarrays 
are so much more "heavy"..is it just that no one has taken the time to 
optimize them, or is there really something inherent (and important) in 
the design?

> As this has become an important path to 
> success of several projects (both commercial and open) it is absolutely 
> necessary that this issues be addressed.

 From the sammll list above, it looks like what you need is an array 
that is like a Numarray, but faster for samll arrays...Has anyone done 
an analysis of whether it would be harder to optimize Numarray than to 
make the above changes to Numeric, and continue to maintain two 
packages? You probably have, but I though I'd ask anyway...

> Ultimately I think it will be a wise 
> thing to have two implementations of arrays: one that is fast and 
> lightweight optimized for many relatively small arrays, and another that 
> is optimized for large-scale arrays.

Are these really incompatable goals?

> If most of the community 
> wants to see Numeric go away then we will be forced to  bring the 
> Numeric array under the SciPy code-base and own it there.

I think it's quite the opposite... if most of the community wants to see 
Numeric continue on, it must be maintained (and improved) with little 
change to the API. If we're all going to switch to Numarray, then the 
SciPy project can do whatever it wants with Numeric...

In Summary:

- Anything called "Numeric" should have a compatable API to the current 
version

- I'd much rather have just one N-d array type, preferable one that is 
part of the Python Standard Library...is likely to ever happen?

- I also want fast small arrays.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov