[Numpy-discussion] Speeding up numarray -- questions on its design

[konrad.hinsen at laposte.net]

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