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

Rich E reakinator@gmail....
Fri Jan 9 16:11:04 CST 2009


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).

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.  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.

So now I can wrap the functions in a way where they are very useful in
python without messing up the c code.  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).

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
>> >
>> >
>
>


More information about the Numpy-discussion mailing list