[Numpy-discussion] Speeding up numarray -- questions on its design
perry at stsci.edu
Wed Jan 19 08:44:18 CST 2005
On Jan 19, 2005, at 7:31 AM, konrad.hinsen at laposte.net wrote:
>> 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
Just to clarify, the intention to make them equivalent was not
originally true (and some encouraged the idea that there be a break
with Numpy compatibility). But that has grown to be a much bigger goal
> 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.
No doubt that supporting both introduces more work, but for the most
part, I think that with the exception of some parts(namely ufunc
C-api), it should be possible write a library that supports both with
little conditional code. That does mean not using some features of
numarray, or depending some of the different behaviors of Numeric
(e.g., scalar coercion rules), so that requires understanding the
subsets to use. And that does cost. But one doesn't need to have two
separate libraries. In such cases I'm hoping there is no need to mix
different flavors of arrays. You either use Numeric arrays consistently
or numarrays consistently. And if the two can be unified, then this
will just be a intermediate solution.
More information about the Numpy-discussion