[Numpy-discussion] Cython numerical syntax revisited

[Dag Sverre Seljebotn]

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