[Numpy-discussion] swig numpy2carray converters
wfspotz at sandia.gov
Tue Nov 20 08:47:29 EST 2007
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
> 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
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:
> 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
> types of 1D typemaps, the
> python function will take a single argument representing DIM1.
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 at sandia.gov **
More information about the NumPy-Discussion