[Numpy-discussion] Please help - pointer to slice

[Sebastian Haase]

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