Francesc Alted wrote:
> A Friday 16 January 2009, j...@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
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
