[SciPy-dev] Inclusion of cython code in scipy
Wed Apr 23 19:55:16 CDT 2008
On Thu, Apr 24, 2008 at 2:22 AM, Anne Archibald
> My goodness, I had no intention of touching off such a discussion.
> On 23/04/2008, Nathan Bell <firstname.lastname@example.org> 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
> 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] 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