Re: [Numpy-discussion] Status of Numeric

[Paul P. <pa...@pr...>]

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 
be slower).

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.

  Paul Prescod