A Thursday 10 September 2009 11:11:22 Sturla Molden escrigué: > Citi, Luca skrev: > > That is exactly why numexpr is faster in these cases. > > I hope one day numpy will be able to perform such > > optimizations. > > I think it is going to require lazy evaluation. Whenever possible, an > operator would just return a symbolic representation of the operation. > This would gradually build up a tree of operators and buffers. When > someone tries to read the data from an array, the buffer is created > on-demand by flushing procratinated expressions. One must be sure that > the buffers referenced in an incomplete expression never change. This > would be easiest to ensure with immutable buffers. Numexpr is the kind > of back-end a system like this would require. But a lot of the code in > numexpr can be omitted because Python creates the parse tree; we would > not need the expression parser in numexpr as frontend. Well... this plan > is gradually getting closer to a specialized SciPy JIT-compiler. I would > be fun to make if I could find time for it.
Numexpr already uses the Python parser, instead of build a new one. However the bytecode emitted after the compilation process is different, of course. Also, I don't see the point in requiring immutable buffers. Could you develop this further? -- Francesc Alted
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
