[Numpy-discussion] Speeding up numarray -- questions on its design
konrad.hinsen at laposte.net
konrad.hinsen at laposte.net
Wed Jan 19 04:48:13 CST 2005
On 19.01.2005, at 04:03, David M. Cooke wrote:
> That's not quite perfect, as the user has to use a mathfuncs object
> also; that's why having Numeric or numarray do the delegation
> automatically is nice.
Exactly. It is an important practical feature of automatic derivatices
that you can use with with nearly any existing mathematical code. If
you have to import the math functions from somewhere else, then you
have to adapt all that code, which in the case of code imported from
some other module means rewriting it.
More importantly, that approach doesn't scale to larger installations.
If two different modules use it to provide generalized math functions,
then the math functions of the two will not be interchangeable.
In fact, it was exactly that kind of missing unversality that was the
motivation for the ufunc code in NumPy ("u" for "universal"). Before
NumPy, we had math (for float) and cmath (for complex), but there was
no simple way to write code that would accept either float or complex
even though that is often useful. Ufuncs would work on float, complex,
arrays of either type, and "anything else" through the method call
mechanism.
> If this was a module instead, you could have registration of types.
> I'll call this module numpy. Here's a possible (low-level) usage:
Yes, a universal module with a registry would be another viable
solution. But the whole community would have to agree on one such
module to make it useful.
> Things to consider with this would be:
> * how to handle a + b
a + b is just operator.add(a, b). The same mechanism would work.
> * where should the registering of types be done? (Probably by the
> packages themselves)
Probably. The method call approach has an advantage here: no registry
is required.
In fact, if we could start all over again, I would argue for a math
function module to be part of core Python that does nothing else but
converting function calls into method calls. After all, math functions
are just syntactic sugar for what functionally *is* a method call.
Konrad.
--
------------------------------------------------------------------------
-------
Konrad Hinsen
Laboratoire Leon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: hinsen at llb.saclay.cea.fr
------------------------------------------------------------------------
-------
More information about the Numpy-discussion
mailing list