[SciPy-dev] Re: [SciPy-user] Low-level code integration discussion at scipy'03?
prabhu at aero.iitm.ernet.in
Wed Sep 3 12:56:59 CDT 2003
>>>>> "FP" == Fernando Perez <fperez at colorado.edu> writes:
[ FP's nice 6d example ]
FP> That's it. ONE line of actual code! A version of this done
FP> with hand loops requires obviously 7 nested for loops. Since
FP> I needed similar code for dimensions 1..6, I wrote
FP> preprocessor macros to generate all versions from a 'template'
FP> (meaning, another macro, not a C++ template<>). This is, of
FP> course, ugly.
Interesting example but I'd imagine that apart from you and some
string theorists (are there any here?) most of us mere mortals would
deal with 3 to 4 d data. ;-) Agreed a one liner is a lot nicer but 3
nested loops are quite normal.
So indeed blitz does have lots of advantages. In fact its the fastest
way to get a 3 fold increase over plain Python Numeric.
FP> Having said that, the above one-liner performs about 3 times
FP> slower than the loop macro version for d=6. For d=1 they are
FP> about even, the blitz one-liner gets worse as d increases. I
FP> posted to the blitz list asking about this, but no response so
>> 3. If plain old inlined C code does indeed perform better than
>> blitz equivalents, it sure would be useful to have the cleaner
>> API anyway. Afterall performance is a key issue here. Having
>> a cleaner API (without fancy expression templates but without
>> having to convert between C++ and Python data) would really be
>> useful in any case.
FP> This, we agree 100% on. In fact, if the C API offered a way
FP> to index high rank arrays without manually computing stride
FP> offsets on every access, that would probably satisfy a
FP> significant fraction of usage cases. I consider one-liners
FP> like the above icing on the cake, but A(i,j,k) indexing is
FP> really a significant change which makes development far more
Great! So we have three strong votes on this on this.
More information about the Scipy-dev