[Numpy-discussion] ANN: Numexpr 1.1, an efficient array evaluator

Dag Sverre Seljebotn dagss@student.matnat.uio...
Fri Jan 16 11:35:59 CST 2009


Francesc Alted wrote:
> A Friday 16 January 2009, jh@physics.ucf.edu escrigué:
>> Right 
>> now, I'm not quite sure whether the problem you are solving is merely
>> the case of expressions-in-strings, and there is no advantage for
>> expressions-in-code, or whether your expressions-in-strings are
>> faster than numpy's expressions-in-code. In either case, it would 
>> appear this would be a good addition to the numpy core, and it's past
>> 1.0, so why keep it separate?  Even if there is value in having a
>> non-numpy version, is there not also value in accelerating numpy by
>> default?
> 
> Having the expression encapsulated in a string has the advantage that 
> you exactly know the part of the code that you want to parse and 
> accelerate.  Making NumPy to understand parts of the Python code that 
> can be accelerated sounds more like a true JIT for Python, and this is 
> something that is not trivial at all (although, with the advent of PyPy 
> there are appearing some efforts in this direction [1]).

A full compiler/JIT isn't needed, there's another route:

One could use the Numexpr methodology together with a symbolic 
expression framework (like SymPy or the one in Sage). I.e. operator 
overloads and lazy expressions.

Combining NumExpr with a symbolic manipulation engine would be very cool 
IMO. Unfortunately I don't have time myself (and I understand that you 
don't, I'm just mentioning it).

Example using psuedo-Sage-like syntax:

a = np.arange(bignum)
b = np.arange(bignum)
x, y = sage.var("x, y")
expr = sage.integrate(x + y, x)
z = expr(x=a, y=b) # z = a**2/2 + b, but Numexpr-enabled

-- 
Dag Sverre


More information about the Numpy-discussion mailing list