[SciPy-dev] Re: [SciPy-user] Low-level code integrationdiscussion at scipy'03?

[Perry Greenfield]

> 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
>
> A[i][j][k][l][m][n]
>
> 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
necessity.
So given that, I (with my admittedly limited imagination :-) can't see
how syntax such as

A(i,j,k,l,m,n)

can work in C (I hope someone can set me straight). Perhaps something
like

Index6d(A,i,j,k,l,m,n)

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
there.)

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.

Perry