[Numpy-discussion] Cython numerical syntax revisited
Dag Sverre Seljebotn
Thu Mar 5 03:11:50 CST 2009
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.
More information about the Numpy-discussion