[Numpy-discussion] Please help - pointer to slice

Sebastian Haase haase at msg.ucsf.edu
Wed Mar 12 09:51:17 CST 2003

> > You are using Numeric  not numarray , right?
> Correct.  I need this stuff for production use, so I just can't quite move
> numarray yet.
> > In any case :
> > My thinking goes as follows:
> > I was looking for a wrapping-solution that would be most transparent to
> > 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
> > to handle the "numarray binding".
> > SWIG has a quite strong (meaning: flexible, general) way of handling
> > 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
> to -say- a Numerical Recipes routine which expects to treat it like a
>   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
> my examples).
> I tried to come up with a solution in C, but managed to convince myself
> it just can't be done.  I was thinking of some typecasting black magic
> the pointers were recast for the pointer arithmetic to hide the column
> offsets, with the proper type still being returned at dereferencing time.
> finally decided this was just impossible in C because the compiler wants
> know the pointer sizes at compile time.  But maybe I'm wrong and just
> 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.
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
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.


More information about the Numpy-discussion mailing list