[Numpy-discussion] Cython numerical syntax revisited

Sturla Molden sturla@molden...
Wed Mar 4 18:11:49 CST 2009


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

I like your proposal. The reason we use Fortran for numerical computing is
that Fortran makes it easy to manipulate arrays. C or C++ sucks terribly
for anything related to numerical computing, and arrays in particular.

Cython is currently not better than C. The ndarray syntax you added last
summer is useless if we need to pass the array or a view/slice to another
function. That is almost always the case. While the syntax is there, the
overhead is unbearable, and it doesn't even work with cdefs. Thus one is
back to working with those pesky C pointers. And they are even more pesky
in Cython, because pointer arithmetics is disallowed.

Currently, I think the best way to use Cython with numpy is to call
PyArray_AsCArray and use the normal C idiom array[i][k][k]. This works
well if we define some array type with C99 restriced pointers:

ctypedef double     *array1D_t "double *restrict"
ctypedef double   **array2D_t "double *restrict *restrict"
ctypedef double ***array3D_t "double *restrict *restrict *restrict"

Thus, having Cython emit C99 takes away some of the pain, but its not
nearly as nice as Fortran and f2py. Creating a subarray will e.g. be very
painful. In Fortran we just slice the array like we do in Python with
NumPy, and the compiler takes care of the rest.


> - 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).

Fortran 90/95 does this already, which is a major reason for chosing it
for numerical computing. If you have something like this working, I
believe many scientists would be happy to retire Fortran. It's not that
anyone likes it that much. Anyhow, I don't see myself retiring Fortran and
f2py any time soon.


Sturla Molden




More information about the Numpy-discussion mailing list