[SciPy-dev] Inclusion of cython code in scipy

Ondrej Certik ondrej@certik...
Wed Apr 23 19:55:16 CDT 2008

On Thu, Apr 24, 2008 at 2:22 AM, Anne Archibald
<peridot.faceted@gmail.com> wrote:
> My goodness, I had no intention of touching off such a discussion.
>  On 23/04/2008, Nathan Bell <wnbell@gmail.com> wrote:
>  > I don't see how writing Cython is easier than writing C/C++/Fortran.
>  >  Clearly if you only know Python, then Cython is an easier language to
>  >  learn.  However, I doubt the Cython abstraction is so complete that
>  >  one can avoid learning C.
>  Here's a concrete example.
>  I recently wrote code to do Lagrange polynomial interpolation using
>  barycentric interpolation (based on Berrut and Trefethen 2004). It's
>  relatively simple code, but it accomplishes a delicate numerical task.
>  I wrote the initial version in python, along with a test suite. It
>  works fine, and is quite stable numerically. But the whole point of
>  interpolation is that it be fast to evaluate, so I thought about how
>  to make it run faster. Since cython was an active topic on the list
>  these days, I thought I'd give it a try, in spite of never having
>  looked into it before.
>  Simply running cython on the file required me to rewrite a couple of
>  in-place operations, but the nearly unmodified file ran fine with no
>  speedups. Annotating the evaluation routine and rewriting the loops
>  took maybe an hour, and got me a fourfold speedup. Annotating the
>  whole class took another couple of hours (remember I'd never done this
>  before), and got me a significant speedup in the construction (my
>  tests report a twenty-fold improvement but I don't much believe that
>  number).
>  Writing cython to do this is easier than writing C to do this. You do
>  not need to know C to do this.
>  There are a number of shortcomings in cython - dealing with numpy
>  arrays could be made vastly easier by one minor change (make A[i]
>  become (<double*>(A.data))[i*A.strides[0]] when A is an ndarray and i
>  is an integer), and documentation is currently sparse, but having
>  tried writing C code to interface with python, I'll take this. I'll
>  even take it over writing raw C. It would also be extremely
>  straightforward to turn it back into python if cython were suddenly
>  wiped from the face of the planet.
>  Whether we want to allow it into scipy is a different question, but I
>  thought a specific example would help focus the discussion. Thus find
>  attached polyint.py, cpolyint.pyx, and test_cpolyint.py.

Thanks for the example, looks good. One comment:


you can leave the range() calls in there (maybe you'll have to change
xrange to range), but it will produce the same C code as your version.


More information about the Scipy-dev mailing list