[Numpy-discussion] Cython numerical syntax revisited

[Dag Sverre Seljebotn]

This is NOT yet discussed on the Cython list; I wanted to check with 
more numerical users to see if the issue should even be brought up there.

The idea behind the current syntax was to keep things as close as 
possible to Python/NumPy, and only provide some "hints" to Cython for 
optimization. My problem with this now is that a) it's too easy to get 
non-optimized code without a warning by letting in untyped indices, b) I 
think the whole thing is a bit too "magic" and that it is too unclear 
what is going on to newcomers (though I'm guessing there).

My proposal: Introduce an explicit "buffer syntax":

arr = np.zeros(..)
cdef int[:,:] buf = arr # 2D buffer

Here, buf would be something else than arr; it is a seperate view to the 
array for low-level purposes.

This has certain disadvantages; consider:

a1 = np.zeros(...) + 1; a2 = np.zeros(...) + 2
cdef int[:] b1 = a1, b2 = a2

Here, one would need to use b1 and b2 for for-loop arithmetic, but a1 
and a2 for vectorized operations and slicing. "b1 + b2" would mean 
something else and not-NumPy-related (at first disallowed, but see below).

"print b1" would likely coerce b1 to a Python memoryview and print 
"<memoryview ...>" (at least on newer Python versions); one would need 
to use some function to get b1 back to a NumPy array.

Advantages:
- More explicit
- Leaves a path open in the syntax for introducing low-level slicing and 
arithmetic as seperate operations in Cython independent of NumPy (think 
Numexpr compile-time folded into Cython code).
- Possible to have some creative syntax like "int[0:]" for disallowing 
negative wraparound and perhaps even "int[-3:]" for non-zero-based indexing.

More details: http://wiki.cython.org/enhancements/buffersyntax

(Of course, compatability with existing code will be taken seriously no 
matter how this plays out!)

-- 
Dag Sverre