On Nov 20, 2007, at 1:12 AM, Georg Holzmann wrote:
The problem I had with numpy.i:
- it copies the arrays on output (Argout Arrays) which was not possible for my algorithms (I have some very big matrices)
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 that is not what you want, then you should probably be using the INPLACE typemap. 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.
- it is not possible to 2D or 3D Argout Arrays (why?), in the docs: ---8<--- Note that we support DATA_TYPE* argout typemaps in 1D, but not 2D or 3D. This because of a quirk with the SWIG typemap syntax and cannot be avoided. Note that for these types of 1D typemaps, the python function will take a single argument representing DIM1. ---8<---
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*.
- I also needed an output of fortran style arrays
This would be a good thing to add to numpy.i.
Yes, of course. Actually I did not want to write that code ;). I was (and still am) a numpy beginner and needed to use my library in it - so all the people said it's so easy to do ... Then I tried boost.python and swig and I spent a lot of time trying to get that work, writing on maiiling lists ... - I did not think before that it would be that hard - and I don't understand why nobody else needed that before.
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.
Maybe this could also be integrated in numpy/doc/swig/numpy.i - but however, this is so much code and I didn't really understand how I should change that to my needs and also asked on the mailinglists ... OTOH the umfpack.i bindings in scipy where quite nice, much easier to read, but of course tuned to their task ...
The numpy.i file does get to be pretty hard to follow, largely because it uses nested macros to handle the large combination of cases. It is a question of how to handle all of the possible use cases. Even so, it would appear that you may have came up with one that wasn't covered, so you see my problem.
Therefore I made these wrappers, which should be easier to understand for beginners, how to write there own wrappers and tune them to their needs.
In the end, though, I think it would be far better to add new capabilities to numpy.i rather than duplicate effort. This will never be as big as the Numeric/numarray split, but still.... 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. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-0154 ** ** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **