[SciPy-dev] Re: [SciPy-user] Low-level code integrationdiscussion at scipy'03?
perry at stsci.edu
Wed Sep 3 13:43:30 CDT 2003
> Perry Greenfield wrote:
> >> 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
> >> FP> productive.
> > Are you just talking about C macros to do the indexing
> (including strides?
> Well, anything which allows me to say in C/C++:
> A(i,j,k,l,m,n) = some_function_of(i,j,k,l,m,n);
> square brackets would also work, though
> starts to feel ugly real quick.
Well, since C is not blessed with convenient handling of multidimensional
array indexing, it would have to be a macro or a function to do this.
A function probably brings in about a factor of 3 penalty for data
access (at least it did a couple years ago when we benchmarked that
approach--hmmm, makes me wonder if blitz resorts to that for large numbers
of dimensions). Mind you, for numarray instances where byteswapped or
nonaligned data are involved, I think a function for indexing is a
So given that, I (with my admittedly limited imagination :-) can't see
how syntax such as
can work in C (I hope someone can set me straight). Perhaps something
it the best that can be done. (A[i][j]...[n] would work but would need
arrays of pointers to pointer to... and I don't think we want to go
On the other hand, syntax like that proposed can be provided in C++.
Still, I'd be very surprised if the blitz people haven't already given
a great deal of thought to this. They probably can explain why it is
slower and why it is difficult to do much better than this.
More information about the Scipy-dev