[SciPy-dev] Re: [SciPy-user] Low-level code integration discussion at scipy'03?
prabhu at aero.iitm.ernet.in
Wed Sep 3 01:25:16 CDT 2003
I have a few opinions on the subject.
>>>>> "FP" == Fernando Perez <fperez at colorado.edu> writes:
FP> A brief summary of the alternatives:
FP> * Scipy's weave relies on blitz, which is extremely nice and
FP> maps surprisingly
FP> well to python arrays. Blitz arrays have slices, ranges,
FP> overloaded arithmetic operators and math functions, etc. In
FP> fact, writing blitz C++ feels almost like writing python code,
FP> with the caveats of handling compile-time type information.
FP> But blitz development seems to be rather slow these days, and
FP> the issue of access to Blas/lapack from blitz isn't fully
FP> settled (i.e., it's not out-of-the box easy).
AFAIK, the other problems with blitz++ and weave are:
1. Blitz is not as fast as a hand coded inline C version. More on
ugliness of code later.
2. Blitz compile times are large.
3. An extra layer of complexity for weave, one more package to keep
track of -- the blitz sources are bundled with weave.
4. With all due respect, not many C++ programmers (forget Python
programmers) would be able to understand/code anything with the
techniques used inside Blitz. Agreed, this is transparent to the
user in the present context but its still worth noting.
FP> * Complete roll-your-own solutions using the Numarray C api.
FP> This is doable,
FP> but after using blitz arrays, it feels really low-level. Call
FP> me lazy, but after using python I've become fully enamored of
FP> writing code which reads as cleanly as possible.
Here is my take. I've always felt that there should be a way to
seamlessly handle Python/C/C++ Numeric arrays using a standard API for
each language. I don't believe I've mentioned it anywhere though and
I am not sure if such a thing exists or not. Numeric/numarray offer
the most commonly used, maintained and popular API for arrays for
numerics in Python. It would be best if a clean C/C++ API would
exist. I'm thinking of a higher level wrapper like class that gives
the C/C++ user a nice API. No re-implementation of the
Numeric/numarray API should be neccessary. If this were done, the
following becomes easily possible:
1. Its easy for C/C++ programmers to use the API and not have to
worry about translating their C code to Python. The translation
should be easy since they are using the standard wrapper API that
uses the raw numeric API underneath.
2. Performance is not too much of an issue since there is no copying
of data back and forth between C/Python and the C++ layer would
most probably be entirely inlined.
3. Writing weave.inline code should be almost as easy as the blitz
version. Agreed blitz is extremely easy to use but if we had a
fairly powerful wrapper API most of the common stuff could be
easily done via this API. Agreed, getting slices to work would be
some work but if there is significant interest, this should also
be possible. In any case the API could be made sufficiently
useable without the need for blitz conversions.
4. Compile times should drop since we aren't really looking to redo
blitz but simply provide a clean Numeric API for C/C++.
>From what I can tell this should solve most problems satisfactorily
and should be useful outside of weave.
More information about the Scipy-dev