[Numpy-discussion] help with typemapping a C function to use numpy arrays

Egor Zindy ezindy@gmail....
Fri Jan 9 20:29:52 CST 2009


Hello again!

On Sat, Jan 10, 2009 at 7:11 AM, Rich E <reakinator@gmail.com> wrote:

> Well I see it works, however with one change: the %apply typemaps need
> to be done before %include'ing the header file, or else nothing in
> that header file will automatically get typemapped (only the functions
> that are written using %inline will be typemapped, which in the case
> of the exampe you wrote, is all there is.  This isn't the case in the
> library I am writing, there are about 20-30 others that don't need to
> be written inline).


There were no typemaps in the example you gave, so it's nice to know you
found where to put the typemaps definition lines in respect to everything
else (this should definitely go in the cookbook!)


>
> One comment though, upon looking at the wrapped c file: there are two
> definitions for sms_spectrumMag(), one that expects pointers to c
> arrays as arguments, and then one later that expects numpy arrays as
> arguments.


I just had a look at the dftmagnitude_wrap.c and I'm confused. If you
understand what's going on, maybe you can shed some light?

The definition for python is contained here:

static PyMethodDef SwigMethods[] = {
     { (char *)"sms_spectrumMag", _wrap_sms_spectrumMag, METH_VARARGS,
NULL},
     { NULL, NULL, 0, NULL }
};

function name on the python side is "sms_spectrumMag"

The _wrap_sms_spectrumMag function the calls either
_wrap_sms_spectrumMag__SWIG_1 (argc == 1)
or
_wrap_sms_spectrumMag__SWIG_0 (argc == 3)

depending on argc = (int)PyObject_Length(args);

.... This is where things become complicated...

_wrap_sms_spectrumMag__SWIG_1 calls my_spectrumMag, the inlined function,

but _wrap_sms_spectrumMag__SWIG_0 doesn't! _wrap_sms_spectrumMag__SWIG_0
calls sms_spectrumMag directly with the 3 arguments converted from python:
int, float * and float *!

Isn't this what we were trying to avoid in the first place? Is there any way
to instruct SWIG not to wrap the function directly?


>  Upon testing the function in python, it seems there is no
> conflict; supplying just a numpy array works perfectly fine.  I dont'
> understand how python is interpreting this so I cannot foresee any
> problems, I'm just bringing it up in case others can.
>

I don't understand either. I thought I did, though! My understanding is that
the function name in python is just a string and can be anything instructed
by the %rename statement. What I don't understand is that SWIG still tries
to wrap the original function, even though we are only interested in
wrapping the %inline-d one.


>
> So now I can wrap the functions in a way where they are very useful in
> python without messing up the c code.


Yup, if you call the python function with the intended number of arguments
(and don't end-up calling the wrapped original function).



>  Great, thank you Egor for the
> ongoing help!  Sorry it took your vacation, but you helped me spend
> mine the way I wanted to (successful programming, hehe).


Don't mention it! I call that a "productive" holiday ;-)

Regards,
Egor


>
> cheers,
> Rich
>
> On Fri, Jan 9, 2009 at 7:05 AM, Egor Zindy <ezindy@gmail.com> wrote:
> > Hello Rich,
> >
> > I know what you mean. %inclusion of header files saves a lot of effort!
> So,
> > I had another play with the code (what holiday this turned out to be;)
> and
> > as long as the declarations in the .i file are made in the right order,
> it
> > should be possible to:
> >   * %include the header file
> >   * %ignore a sms_ function
> >   * %rename the function my_ to sms_
> >   * %inline the my_ function
> >
> > I changed the .i file (attached) and re-ran the test, it works. Again,
> this
> > is on my XP/cygwin/mingw32 system, so it could need some tuning on a
> > different system!
> >
> > In all this, not sure where is best to put the %exception statement, but
> > placement shouldn't be critical, because it concerns the my_ function
> rather
> > than the original (or renamed) sms_ function.
> >
> > Regards,
> > Egor
> >
> > On Fri, Jan 9, 2009 at 5:43 AM, Rich E <reakinator@gmail.com> wrote:
> >>
> >> I am using %includ "sms.h", which is what is wrapping all my
> >> functions.  Without doing this, I have to hand-wrap every function in
> >> the header file!
> >>
> >> Is there a way to exclude certain definitions from my c header file
> >> when using %include, so that I can hand wrap them instead?
> >>
> >> On Thu, Jan 8, 2009 at 2:13 AM, Egor Zindy <ezindy@gmail.com> wrote:
> >> > Hello Rich,
> >> >
> >> > This is very strange. I got to test my example again, as long as you
> >> > don't
> >> > do a
> >> > %include "dftmagnitude.h"
> >> > somewhere in the dftmagnitude.i, it's perfectly possible to do a
> >> > %rename (sms_spectrumMag) my_spectrumMag;
> >> > (see dftmagnitude3.zip attached in my previous mail and this one).
> >> >
> >> > So things for you to check:
> >> >   * does the simple dftmagnitude3.zip compile on your system?
> >> >   * what version of SWIG are you using? (I used 1.3.36 provided with
> >> > cygwin)
> >> >   * do you have a %include statement somewhere in your own .i file?
> >> >
> >> > Matthieu, if you read this, there's a complete example provided in
> >> > dftmagnitude3.zip.
> >> >   * Wrapped function sms_spectrumMag in dftmagnitude.c and .h
> >> >   * SWIG wrapper dftmagnitude.i uses %inline and %rename statements
> >> >   * Example uses a modified numpy.i (see the previous mails in the
> >> > thread).
> >> >   * test example provided in test_dftmagnitude.py
> >> >
> >> > Haven't tested it under Linux, but under winxp/cygwin/mingw32, the
> >> > following
> >> > works for me (in cygwin):
> >> >
> >> > $ python setup_dftmagnitude.py build -cmingw32 ; mv
> >> > build/lib.win32-2.5/_dftmagnitude.pyd .
> >> > $ python test_dftmagnitude.py
> >> >
> >> > Regards,
> >> > Egor
> >> >
> >> > --
> >> > My Python:
> >> > $ python -i
> >> > Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> >> > (Intel)]
> >> > on win32
> >> >
> >> > My SWIG:
> >> > $ swig -version
> >> >
> >> > SWIG Version 1.3.36
> >> >
> >> > Compiled with g++ [i686-pc-cygwin]
> >> > Please see http://www.swig.org for reporting bugs and further
> >> > information
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Jan 8, 2009 at 1:43 AM, Rich E <reakinator@gmail.com> wrote:
> >> >>
> >> >> Here is my example, trying to wrap the function sms_spectrumMag that
> >> >> we have been dealing with:
> >> >>
> >> >> %apply (int DIM1, float* IN_ARRAY1) {(int sizeInArray, float*
> >> >> pInArray)};
> >> >> %apply (int DIM1, float* INPLACE_ARRAY1) {(int sizeOutArray, float*
> >> >> pOutArray)};
> >> >>
> >> >> %inline %{
> >> >>
> >> >>        void my_spectrumMag( int sizeInArray, float *pInArray, int
> >> >> sizeOutArray, float *pOutArray)
> >> >>        {
> >> >>                sms_spectrumMag(sizeOutArray, pInArray, pOutArray);
> >> >>        }
> >> >>
> >> >> %}
> >> >>
> >> >>
> >> >> at this point,  have the new function my_spectrumMag that wraps
> >> >> sms_spectrumMag() and provides arguments that can be typemapped using
> >> >> numpy.i  Now, I don't want to have to call the function
> >> >> my_spectrumMag() in python, I want to use the original name, I would
> >> >> like to call the function as:
> >> >>
> >> >> sms_spectrumMag(numpyArray1, numpyArray2)
> >> >>
> >> >> But, trying to %rename my_spectrumMag to sms_spectrumMag does not
> >> >> work, the original sms_spectrumMag gets called in python instead.
> >> >> Trying to %ignore the original function first as follows removes the
> >> >> sms_spectrumMag completely from the module and I am left with
> >> >> my_spectrumMag:
> >> >>
> >> >> %ignore sms_spectrumMag;
> >> >> %rename (sms_spectrumMag) my_spectrumMag;
> >> >>
> >> >>
> >> >> Do you see my problem?
> >> >>
> >> >>
> >> >> On Wed, Jan 7, 2009 at 8:58 AM, Matthieu Brucher
> >> >> <matthieu.brucher@gmail.com> wrote:
> >> >> > 2009/1/6 Rich E <reakinator@gmail.com>:
> >> >> >> This helped immensely.  I feel like I am getting close to being
> able
> >> >> >> to accomplish what I would like with SWIG: producing a python
> module
> >> >> >> that can be very 'python-like', while co-existing with the c
> library
> >> >> >> that is very 'c-like'.
> >> >> >>
> >> >> >> There is one question still remaining though, is it possible to
> make
> >> >> >> the wrapped function have the same name still?  Using either
> >> >> >> my_spectrumMag or spectrumMag means I have to create a number of
> >> >> >> inconsistencies between the python module and the c library.  It
> is
> >> >> >> ideal to ignore (%ignore?) the c sms_spectrumMag and instead use
> the
> >> >> >> wrapped one, with the same name.  But my attempts at doing this so
> >> >> >> far
> >> >> >> have not compiled because of name conflictions.
> >> >> >
> >> >> > Ok course you can. The function is renamed only if you say so.
> >> >> > Perhaps
> >> >> > can you provide a small example of what doesn't work at the moment
> ?
> >> >> >
> >> >> >> Thanks for the help, I think you are doing great things with this
> >> >> >> numpy interface/typemaps system.
> >> >> >
> >> >> > Matthieu
> >> >> > --
> >> >> > Information System Engineer, Ph.D.
> >> >> > Website: http://matthieu-brucher.developpez.com/
> >> >> > Blogs: http://matt.eifelle.com and
> >> >> > http://blog.developpez.com/?blog=92
> >> >> > LinkedIn: http://www.linkedin.com/in/matthieubrucher
> >> >> > _______________________________________________
> >> >> > Numpy-discussion mailing list
> >> >> > Numpy-discussion@scipy.org
> >> >> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> >> >> >
> >> >> _______________________________________________
> >> >> Numpy-discussion mailing list
> >> >> Numpy-discussion@scipy.org
> >> >> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> >> >
> >> >
> >> > _______________________________________________
> >> > Numpy-discussion mailing list
> >> > Numpy-discussion@scipy.org
> >> > http://projects.scipy.org/mailman/listinfo/numpy-discussion
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20090110/1340fe07/attachment.html 


More information about the Numpy-discussion mailing list