[Numpy-discussion] swig numpy2carray converters

[Georg Holzmann]

Hallo!

> Really?  I worked pretty hard to avoid copies when they were not  
> necessary.  For the ARGOUT typemaps, I allocate an array of the  
> requested size and then pass its data buffer to your function.  If  

Yes but this means that you again allocate an array of the same size.
E.g. in my algorithm I can have a very big internal matrix in C++ (say 
700 MB - in fortran style). Now I want to have this matrix in numpy to 
plot some parts of it, get some data out of it ... whatever - if I again 
allocate an array of the same size, I am out of memory.
Therefore I simply used the PyArray_FromDimsAndData() function to 
allocate the array.

BTW: for me this also seems to be more the "numpy way", because usually 
numpy doesn't copy data. And if I want to copy this data I can simply 
call .copy() in python - however, there is of course the risk that this 
data is freed in C and you can have a crash ... so maybe this is no good 
idea for a general interface ...

> that is not what you want, then you should probably be using the  
> INPLACE typemap.

Yeah, but this results in the same as above ...

> Do you have some different use case?  If so, it would be far better  
> for us (me) to add this to numpy.i, which covers more data types  
> (especially dimension data types) and has a lot more error checking  
> in it, rather than develop yet another numpy/swig interface file.

Yes I would very much appreciate that.
My use case is (as described above) an ARGOUT 1D and/or 2D array in C 
and/or Fortran style storage without copying the data (and also not 
allocating it again).

> I don't see where your numpy2carray.i file handles arrays greater  
> than 1D either.  Doing a search on "argout", the corresponding  
> typemaps all apply to ttype*.

Hm ... maybe this is a misunderstanding ? - I mean with 2D output a two 
dimensional numpy array (simply a matrix).
In numpy2carray.i the macros are called ARRAY2_OUT and FARRAY2_OUT.

> I follow both the swig and numpy mail lists.  I don't see any posts  
> from you prior to 10/25/07.  I probably just skimmed past your first  
> posts because the subject referred to fortran, so I assumed you were  
> dealing with fortran code.  Sorry about that.

I did not write to the swig list - I think it was the [C++-sig], but 
however, thats no longer important ... ;)

> In the end, though, I think it would be far better to add new  
> capabilities to numpy.i rather than duplicate effort.  This will  

of course ...

> Let me know what you are trying to do.  If numpy.i can do it, I'll  
> show you how.  If not, I'll work to upgrade numpy.i.  I suspect it  
> can do everything except the fortran ordering.

Again, see above for my use case.
But the fortran ordering should not be that hard (only setting the flags 
and strides right, as in FARRAY2_OUT in numpy2carray.i) - but of course 
someone has to do it ... ;)

LG
Georg