...

You are using Numeric not numarray , right?

Correct. I need this stuff for production use, so I just can't quite move to numarray yet.

...

In any case : My thinking goes as follows: I was looking for a wrapping-solution that would be most transparent to the people that would write the C/C++ code (or even Fortran, BTW) Since I already had some experience using SWIG, that's what I wanted to use to handle the "numarray binding". SWIG has a quite strong (meaning: flexible, general) way of handling data types. They call it "type maps": Once you have that in place (later more) the whole "binding" looks like this: (an example)

[Snip]

Does your stuff handle non-contiguity transparently? I couldn't quite find a solution for that, which means that a **pointer I get can't be blindly passed to -say- a Numerical Recipes routine which expects to treat it like a matrix. If it's contiguous all is fine, but otherwise one needs to either make a copy or handle the 'skipping' by hand in the column-index loops (as shown in my examples).

I tried to come up with a solution in C, but managed to convince myself that it just can't be done. I was thinking of some typecasting black magic where the pointers were recast for the pointer arithmetic to hide the column offsets, with the proper type still being returned at dereferencing time. I finally decided this was just impossible in C because the compiler wants to know the pointer sizes at compile time. But maybe I'm wrong and just didn't think about the problem hard enough.

At any rate, I'd be interested in seeing your typemap stuff. Especially if it either works with Numeric or it can be modified for Numeric use with reasonably limited effort.

Fernando, Sorry, I forgot to comment on the "non-contiguity " question... First: My last post contained practically everything there is to typemapping needed when you use SWIG. ("practically" means that I have many versions of that for handling other types (like short, int, complex, ...) and fro handling 2d arrays.) Do YOU know SWIG ? "handle non-contiguity transparently" What are exactly the possible scenarios of "non-contiguous" ? If, for example having a 3d array, only going along the first axis is non-c. but along the other ones still is, I could imagine that it would not be to problematic to "forward" that scheme into the C side, that is: in a non-transparent way. The only alternative I see would be introducing some macros to translate each memory pointer. But that would also not be transparent ( since the C side would have to use these "wired" macros) and I is like to be slower, because of all the new pointer arithmetic (inside those macros) I would favor the the first scenario. Regards, Sebastian