[Numpy-discussion] Status of Numeric
Chris.Barker at noaa.gov
Tue Jan 20 11:13:05 CST 2004
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
> 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...
- Anything called "Numeric" should have a compatable API to the current
- 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.
Christopher Barker, Ph.D.
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
More information about the Numpy-discussion