[Numpy-discussion] Status of Numeric
paul at prescod.net
Thu Jan 22 23:31:01 CST 2004
Perry Greenfield wrote:
> We had looked at it at least a couple of times. I don't remember now
> all the conclusions, but I think one of the problems was that
> it wasn't as useful when one had to deal with data types not
> used in python itself (e.g., unsigned int16). I might be wrong
> about that.
I would guess that the issue is more whether it is natively handled by
Pyrex than whether it is handled by Python. Is there a finite list of
these types that Numarray handles? If you have a list I could generate a
patch to Pyrex that would support them. We could then ask Greg whether
he could add them to Pyrex core or refactor it so that he doesn't have to.
> Numarray generates a lot of c code directly for the actual
> array computations. That is neither the slow part, nor the
> hard part to write. It is the array computation setup that
> is complicated. Much of that is now in C (and we do worry
> that it has greatly added to the complexity). Perhaps that
> part could be better handled by pyrex.
It sounds like it.
> I think some of the remaining overhead has to do with intrinsic
> python calls, and the differences between the simpler type used
> for Numeric versus the new style classes used for numarray.
> Don't hold me to that however.
Pyrex may be able to help with at least one of these. Calls between
Pyrex-coded functions usually go at C speeds (although method calls may
I don't know enough about the new-style, old-style issue to know about
whether Pyrex can help with that but I would guess it might because a
Pyrex "extension type" is more like a C extension type than a Python
instance object. That implies some faster method lookup and calling.
Numeric is the exact type of project Pyrex is designed for. And of
course it works seamlessly with pre-existing Python and C code so you
can selectively port things.
More information about the Numpy-discussion