Francesc Alted wrote:
A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué:
But yes, to implement that one would need to reimplement parts of NumPy to get it working. But because code would be generated specifically for the situation inline, I think it would be more like reimplementing Numexpr than reimplementing NumPy. I think one could simply invoke Numexpr as a first implementation (and make it an optional Cython plugin).
At first sight, having a kind of Numexpr kernel inside Cython would be great, but provided that you can already call Numexpr from both Python/Cython, I wonder which would be the advantage to do so. As I see it, it would be better to have:
c = numexpr.evaluate("a + b")
in the middle of Cython code than just:
c = a + b
in the sense that the former would allow the programmer to see whether Numexpr is called explicitely or not.
The former would need to invoke the parser etc., which one would *not* need to do when one has the Cython compilation step. When I mention numexpr it is simply because there's gone work in it already to optimize these things; that experience could hopefully be kept, while discarding the parser and opcode system. I know too little about these things, but look: Cython can relatively easily transform things like cdef int[:,:] a = ..., b = ... c = a + b * b into a double for-loop with c[i,j] = a[i,j] + b[i,j] * b[i,j] at its core. A little more work could have it iterate the smallest dimension innermost dynamically (in strided mode). If a and b are declared as contiguous arrays and "restrict", I suppose the C compiler could do the most efficient thing in a lot of cases? (I.e. "cdef restrict int[:,:,"c"]" or similar) However if one has a strided array, numexpr could still give an advantage over such a loop. Or? But anyway, this is easily one year ahead of us, unless more numerical Cython developers show up. -- Dag Sverre