# [Numpy-discussion] Cython numerical syntax revisited

Dag Sverre Seljebotn dagss@student.matnat.uio...
Wed Mar 4 16:24:40 CST 2009

```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
```

More information about the Numpy-discussion mailing list