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

Perry Greenfield 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
>
> 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




More information about the Scipy-dev mailing list