[Numpy-discussion] Status of Numeric

[Francesc Alted]

A Divendres 23 Gener 2004 08:24, Paul Prescod va escriure:
> 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.

I think the question rather was whether Pyrex would be able to work with
templates (in the sense of C++), i.e. it can generate different functions
depending on the datatypes passed to them.

You can see some previous discussion on that list in:

http://sourceforge.net/mailarchive/forum.php?thread_id=1642778&forum_id=4890

I've formulated the question to Greg and here you are his answer:

http://sourceforge.net/mailarchive/forum.php?thread_id=1645713&forum_id=4890

So, it seems that he don't liked the idea to implement "templates" in Pyrex.

>
> > 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.

Yeah, I'm quite convinced that a mix between Pyrex and the existing solution
in numarray for dealing with templates could be worth the effort.  At least,
some analysis could be done on that aspect.

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

Well, that should be clarified: that's only true for cdef's pyrex functions
(i.e. C functions made in Pyrex). Pyrex functions that are able to be called
from Python takes the same time whether they are called from Python or from
the same Pyrex extension.

See some timmings I've done on that subject some time ago:

http://sourceforge.net/mailarchive/message.php?msg_id=3782230

Cheers,

-- 
Francesc Alted
Departament de Ciències Experimentals
Universitat Jaume I. Castelló de la Plana. Spain