[Numpy-discussion] swig numpy2carray converters

Bill Spotz 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  
> 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 at sandia.gov **

More information about the NumPy-Discussion mailing list