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