help with typemapping a C function to use numpy arrays

Hi list, My question has to do with the Numpy/SWIG typemapping system. I recently got the typemaps in numpy.i to work on most of my C functions that are wrapped using SWIG, if they have arguments of the form (int sizeArray, float *pArray). Now I am trying to figure out how to wrap function that aren't of the form, such as the following function: /*! \brief compute magnitude spectrum of a DFT * * \param sizeMag size of output Magnitude (half of input real FFT) * \param pFReal pointer to input FFT real array (real/imag floats) * \param pFMAg pointer to float array of magnitude spectrum */ void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag) { int i, it2; float fReal, fImag; for (i=0; i<sizeMag; i++) { it2 = i << 1; fReal = pInRect[it2]; fImag = pInRect[it2+1]; pOutMag[i] = sqrtf(fReal * fReal + fImag * fImag); } } There are two arrays, one is half the size of the other. But, SWIG doesn't know this, according to the type map it will think *pInRect is of size sizeMag and will not know anything about *pOutMag. Ideally in python, I would like to call the function as sms_spectrumMag(nArray1, nArray2), where nArray1 is twice the size of nArray2, and nArray2 is of size sizeMag. I think in order to do this (although if someone has a better suggestion, I am open to it), I will have to modify the typemap in order to tell SWIG how to call the C function properly. I do not want to have to edit the wrapped C file every time it is regenerated from the interface file. Here is a start I made with the existing typemap code in numpy.i (not working): /* Typemap suite for (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) */ %typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY, fragment="NumPy_Macros") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) { $1 = is_array($input) && PyArray_EquivTypenums(array_type($input), DATA_TYPECODE); } %typemap(in, fragment="NumPy_Fragments") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) (PyArrayObject* array=NULL, int i=0) { array = obj_to_array_no_conversion($input, DATA_TYPECODE); if (!array || !require_dimensions(array,1) || !require_contiguous(array) || !require_native(array)) SWIG_fail; $1 = 1; for (i=0; i < array_numdims(array); ++i) $1 *= array_size(array,i); $2 = (DATA_TYPE*) array_data(array); } and try to alter it to allow for a conversion of type: (DIM_TYPE DIM1, DATA_TYPE* ARRAY1, DATA_TYPE* ARRAY2) where ARRAY1 is size DIM1 * 2 and ARRAY2 is size DIM1. Then I can %apply this to my function that I mentioned in the last post. So here are my first two questions: 1) where is DIM1 used to declare the array size? I don't see where it is used at all, and I need to somewhere multiply it by 2 to declare the size of ARRAY1 2) I am not understanding where $input comes from, so I do not understand how to distinguish between ARRAY1 and ARRAY2. In the attempt I have already tried, I think I just use the pointer to ARRAY1 twice. If anyone has suggestions on how to solve this problem, thanks! regards, Rich

Hello Rich, sorry it took so long to answer back, holidays and all :-) That's exactly the kind of SWIG / numpy.i problems I've been working on over the past few months: How to generate an array you don't know the size of a-priori, and then handle the memory deallocation seamlessly. In your case, you know that the output array will be half the size of the input array, but this falls under the more general case of "not knowing the output size a-priori". Have a look at the files attached. I've rewritten your function header as: void sms_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag); Easy to see what the input and output arrays are now. Then my numpy.i handles the memory deallocation of the **pOutMag array. I've actually moved my numpy.i explanations to the scipy/numpy cookbook last week :-) http://www.scipy.org/Cookbook/SWIG_Memory_Deallocation Hope it all makes sense. If you have any questions, don't hesitate!
python test_dftmagnitude.py [1, 1, 2, 2] [ 1.41421354 2.82842708] [1, 1, 2, 2, 3, 3, 4, 4] [ 1.41421354 2.82842708 4.2426405 5.65685415] [1, 1, 2, 2, 3, 3, 4, 4, 5, 5] [ 1.41421354 2.82842708 4.2426405 5.65685415 7.07106781]
Regards, Egor On Wed, Dec 24, 2008 at 1:52 AM, Rich E <reakinator@gmail.com> wrote:
Hi list,
My question has to do with the Numpy/SWIG typemapping system.
I recently got the typemaps in numpy.i to work on most of my C functions that are wrapped using SWIG, if they have arguments of the form (int sizeArray, float *pArray).
Now I am trying to figure out how to wrap function that aren't of the form, such as the following function:
/*! \brief compute magnitude spectrum of a DFT * * \param sizeMag size of output Magnitude (half of input real FFT) * \param pFReal pointer to input FFT real array (real/imag floats) * \param pFMAg pointer to float array of magnitude spectrum */ void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag) { int i, it2; float fReal, fImag;
for (i=0; i<sizeMag; i++) { it2 = i << 1; fReal = pInRect[it2]; fImag = pInRect[it2+1]; pOutMag[i] = sqrtf(fReal * fReal + fImag * fImag); } }
There are two arrays, one is half the size of the other. But, SWIG doesn't know this, according to the type map it will think *pInRect is of size sizeMag and will not know anything about *pOutMag.
Ideally in python, I would like to call the function as sms_spectrumMag(nArray1, nArray2), where nArray1 is twice the size of nArray2, and nArray2 is of size sizeMag.
I think in order to do this (although if someone has a better suggestion, I am open to it), I will have to modify the typemap in order to tell SWIG how to call the C function properly. I do not want to have to edit the wrapped C file every time it is regenerated from the interface file.
Here is a start I made with the existing typemap code in numpy.i (not working):
/* Typemap suite for (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) */ %typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY, fragment="NumPy_Macros") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) { $1 = is_array($input) && PyArray_EquivTypenums(array_type($input), DATA_TYPECODE); } %typemap(in, fragment="NumPy_Fragments") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) (PyArrayObject* array=NULL, int i=0) { array = obj_to_array_no_conversion($input, DATA_TYPECODE); if (!array || !require_dimensions(array,1) || !require_contiguous(array) || !require_native(array)) SWIG_fail; $1 = 1; for (i=0; i < array_numdims(array); ++i) $1 *= array_size(array,i); $2 = (DATA_TYPE*) array_data(array); }
and try to alter it to allow for a conversion of type: (DIM_TYPE DIM1, DATA_TYPE* ARRAY1, DATA_TYPE* ARRAY2) where ARRAY1 is size DIM1 * 2 and ARRAY2 is size DIM1. Then I can %apply this to my function that I mentioned in the last post.
So here are my first two questions:
1) where is DIM1 used to declare the array size? I don't see where it is used at all, and I need to somewhere multiply it by 2 to declare the size of ARRAY1
2) I am not understanding where $input comes from, so I do not understand how to distinguish between ARRAY1 and ARRAY2. In the attempt I have already tried, I think I just use the pointer to ARRAY1 twice.
If anyone has suggestions on how to solve this problem, thanks!
regards, Rich _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Egor, Thanks for the help. I think I want to leave the C code as-is however, as it is perfectly fine there no knowing 'sizeOutMag' because it can deduce both array sizes from one variable. There are many other similar cases in my code (many where the size of the array is known by a member of a structure passed to the function). Maybe I should look into using an 'insertion block' of code in the interface file, instead of trying to typemap the array? I am thinking I may just be able to copy the generated code (from SWIG) into my interface file to do this, but I have not tried it yet. I will experiment a little and post again. Thanks and happy holidays! regards, Rich On Mon, Jan 5, 2009 at 10:42 AM, Egor Zindy <ezindy@gmail.com> wrote:
Hello Rich,
sorry it took so long to answer back, holidays and all :-)
That's exactly the kind of SWIG / numpy.i problems I've been working on over the past few months: How to generate an array you don't know the size of a-priori, and then handle the memory deallocation seamlessly. In your case, you know that the output array will be half the size of the input array, but this falls under the more general case of "not knowing the output size a-priori".
Have a look at the files attached. I've rewritten your function header as: void sms_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag);
Easy to see what the input and output arrays are now. Then my numpy.i handles the memory deallocation of the **pOutMag array.
I've actually moved my numpy.i explanations to the scipy/numpy cookbook last week :-) http://www.scipy.org/Cookbook/SWIG_Memory_Deallocation
Hope it all makes sense. If you have any questions, don't hesitate!
python test_dftmagnitude.py [1, 1, 2, 2] [ 1.41421354 2.82842708] [1, 1, 2, 2, 3, 3, 4, 4] [ 1.41421354 2.82842708 4.2426405 5.65685415] [1, 1, 2, 2, 3, 3, 4, 4, 5, 5] [ 1.41421354 2.82842708 4.2426405 5.65685415 7.07106781]
Regards, Egor
On Wed, Dec 24, 2008 at 1:52 AM, Rich E <reakinator@gmail.com> wrote:
Hi list,
My question has to do with the Numpy/SWIG typemapping system.
I recently got the typemaps in numpy.i to work on most of my C functions that are wrapped using SWIG, if they have arguments of the form (int sizeArray, float *pArray).
Now I am trying to figure out how to wrap function that aren't of the form, such as the following function:
/*! \brief compute magnitude spectrum of a DFT * * \param sizeMag size of output Magnitude (half of input real FFT) * \param pFReal pointer to input FFT real array (real/imag floats) * \param pFMAg pointer to float array of magnitude spectrum */ void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag) { int i, it2; float fReal, fImag;
for (i=0; i<sizeMag; i++) { it2 = i << 1; fReal = pInRect[it2]; fImag = pInRect[it2+1]; pOutMag[i] = sqrtf(fReal * fReal + fImag * fImag); } }
There are two arrays, one is half the size of the other. But, SWIG doesn't know this, according to the type map it will think *pInRect is of size sizeMag and will not know anything about *pOutMag.
Ideally in python, I would like to call the function as sms_spectrumMag(nArray1, nArray2), where nArray1 is twice the size of nArray2, and nArray2 is of size sizeMag.
I think in order to do this (although if someone has a better suggestion, I am open to it), I will have to modify the typemap in order to tell SWIG how to call the C function properly. I do not want to have to edit the wrapped C file every time it is regenerated from the interface file.
Here is a start I made with the existing typemap code in numpy.i (not working):
/* Typemap suite for (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) */ %typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY, fragment="NumPy_Macros") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) { $1 = is_array($input) && PyArray_EquivTypenums(array_type($input), DATA_TYPECODE); } %typemap(in, fragment="NumPy_Fragments") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) (PyArrayObject* array=NULL, int i=0) { array = obj_to_array_no_conversion($input, DATA_TYPECODE); if (!array || !require_dimensions(array,1) || !require_contiguous(array) || !require_native(array)) SWIG_fail; $1 = 1; for (i=0; i < array_numdims(array); ++i) $1 *= array_size(array,i); $2 = (DATA_TYPE*) array_data(array); }
and try to alter it to allow for a conversion of type: (DIM_TYPE DIM1, DATA_TYPE* ARRAY1, DATA_TYPE* ARRAY2) where ARRAY1 is size DIM1 * 2 and ARRAY2 is size DIM1. Then I can %apply this to my function that I mentioned in the last post.
So here are my first two questions:
1) where is DIM1 used to declare the array size? I don't see where it is used at all, and I need to somewhere multiply it by 2 to declare the size of ARRAY1
2) I am not understanding where $input comes from, so I do not understand how to distinguish between ARRAY1 and ARRAY2. In the attempt I have already tried, I think I just use the pointer to ARRAY1 twice.
If anyone has suggestions on how to solve this problem, thanks!
regards, Rich _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Hello again, I really don't know what came over me when I changed your function prototype, that wasn't a very thoughtful thing to do! Maybe I should look into using an 'insertion block' of code in the
interface file, instead of trying to typemap the array?
Insertion blocks... is that %inline code? In which case, yes! Have a look, I attached a new version that uses some %inline directives in the dftmagnitude.i file. Basically, you can inline a new function with an easier prototype to wrap. The function allocates memory and calls your sms_spectrumMag() function. my inline function: void my_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag) there's also a %rename directive: %rename (spectrumMag) my_spectrumMag; I had a go at defining some exceptions too (no memory and odd number of indexes), but I'm not sure errno is the easiest way to go about it... Hope this helps! ... and the python test output: ~>python test_dftmagnitude.py array: [1, 1, 2, 2] result: [ 1.41421354 2.82842708] array: [1, 1, 2, 2, 3, 3, 4, 4] result: [ 1.41421354 2.82842708 4.2426405 5.65685415] array: [1, 1, 2] result: Traceback (most recent call last): File "test_dftmagnitude.py", line 15, in <module> print "result:",dftmagnitude.spectrumMag(a) IndexError: Odd number of elements in input array: 3 ~> Regards, Egor On Tue, Jan 6, 2009 at 1:06 AM, Rich E <reakinator@gmail.com> wrote:
Egor,
Thanks for the help. I think I want to leave the C code as-is however, as it is perfectly fine there no knowing 'sizeOutMag' because it can deduce both array sizes from one variable. There are many other similar cases in my code (many where the size of the array is known by a member of a structure passed to the function).
Maybe I should look into using an 'insertion block' of code in the interface file, instead of trying to typemap the array? I am thinking I may just be able to copy the generated code (from SWIG) into my interface file to do this, but I have not tried it yet.
I will experiment a little and post again. Thanks and happy holidays!
regards, Rich
On Mon, Jan 5, 2009 at 10:42 AM, Egor Zindy <ezindy@gmail.com> wrote:
Hello Rich,
sorry it took so long to answer back, holidays and all :-)
That's exactly the kind of SWIG / numpy.i problems I've been working on over the past few months: How to generate an array you don't know the size of a-priori, and then handle the memory deallocation seamlessly. In your case, you know that the output array will be half the size of the input array, but this falls under the more general case of "not knowing the output size a-priori".
Have a look at the files attached. I've rewritten your function header as: void sms_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag);
Easy to see what the input and output arrays are now. Then my numpy.i handles the memory deallocation of the **pOutMag array.
I've actually moved my numpy.i explanations to the scipy/numpy cookbook last week :-) http://www.scipy.org/Cookbook/SWIG_Memory_Deallocation
Hope it all makes sense. If you have any questions, don't hesitate!
python test_dftmagnitude.py [1, 1, 2, 2] [ 1.41421354 2.82842708] [1, 1, 2, 2, 3, 3, 4, 4] [ 1.41421354 2.82842708 4.2426405 5.65685415] [1, 1, 2, 2, 3, 3, 4, 4, 5, 5] [ 1.41421354 2.82842708 4.2426405 5.65685415 7.07106781]
Regards, Egor
On Wed, Dec 24, 2008 at 1:52 AM, Rich E <reakinator@gmail.com> wrote:
Hi list,
My question has to do with the Numpy/SWIG typemapping system.
I recently got the typemaps in numpy.i to work on most of my C functions that are wrapped using SWIG, if they have arguments of the form (int sizeArray, float *pArray).
Now I am trying to figure out how to wrap function that aren't of the form, such as the following function:
/*! \brief compute magnitude spectrum of a DFT * * \param sizeMag size of output Magnitude (half of input real FFT) * \param pFReal pointer to input FFT real array (real/imag floats) * \param pFMAg pointer to float array of magnitude spectrum */ void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag) { int i, it2; float fReal, fImag;
for (i=0; i<sizeMag; i++) { it2 = i << 1; fReal = pInRect[it2]; fImag = pInRect[it2+1]; pOutMag[i] = sqrtf(fReal * fReal + fImag * fImag); } }
There are two arrays, one is half the size of the other. But, SWIG doesn't know this, according to the type map it will think *pInRect is of size sizeMag and will not know anything about *pOutMag.
Ideally in python, I would like to call the function as sms_spectrumMag(nArray1, nArray2), where nArray1 is twice the size of nArray2, and nArray2 is of size sizeMag.
I think in order to do this (although if someone has a better suggestion, I am open to it), I will have to modify the typemap in order to tell SWIG how to call the C function properly. I do not want to have to edit the wrapped C file every time it is regenerated from the interface file.
Here is a start I made with the existing typemap code in numpy.i (not working):
/* Typemap suite for (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) */ %typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY, fragment="NumPy_Macros") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) { $1 = is_array($input) && PyArray_EquivTypenums(array_type($input), DATA_TYPECODE); } %typemap(in, fragment="NumPy_Fragments") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) (PyArrayObject* array=NULL, int i=0) { array = obj_to_array_no_conversion($input, DATA_TYPECODE); if (!array || !require_dimensions(array,1) ||
!require_contiguous(array)
|| !require_native(array)) SWIG_fail; $1 = 1; for (i=0; i < array_numdims(array); ++i) $1 *= array_size(array,i); $2 = (DATA_TYPE*) array_data(array); }
and try to alter it to allow for a conversion of type: (DIM_TYPE DIM1, DATA_TYPE* ARRAY1, DATA_TYPE* ARRAY2) where ARRAY1 is size DIM1 * 2 and ARRAY2 is size DIM1. Then I can %apply this to my function that I mentioned in the last post.
So here are my first two questions:
1) where is DIM1 used to declare the array size? I don't see where it is used at all, and I need to somewhere multiply it by 2 to declare the size of ARRAY1
2) I am not understanding where $input comes from, so I do not understand how to distinguish between ARRAY1 and ARRAY2. In the attempt I have already tried, I think I just use the pointer to ARRAY1 twice.
If anyone has suggestions on how to solve this problem, thanks!
regards, Rich _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

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. Thanks for the help, I think you are doing great things with this numpy interface/typemaps system. regards, Rich On Tue, Jan 6, 2009 at 3:47 PM, Egor Zindy <ezindy@gmail.com> wrote:
Hello again,
I really don't know what came over me when I changed your function prototype, that wasn't a very thoughtful thing to do!
Maybe I should look into using an 'insertion block' of code in the interface file, instead of trying to typemap the array?
Insertion blocks... is that %inline code? In which case, yes! Have a look, I attached a new version that uses some %inline directives in the dftmagnitude.i file.
Basically, you can inline a new function with an easier prototype to wrap. The function allocates memory and calls your sms_spectrumMag() function.
my inline function: void my_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag)
there's also a %rename directive: %rename (spectrumMag) my_spectrumMag;
I had a go at defining some exceptions too (no memory and odd number of indexes), but I'm not sure errno is the easiest way to go about it...
Hope this helps!
... and the python test output:
~>python test_dftmagnitude.py array: [1, 1, 2, 2] result: [ 1.41421354 2.82842708]
array: [1, 1, 2, 2, 3, 3, 4, 4] result: [ 1.41421354 2.82842708 4.2426405 5.65685415]
array: [1, 1, 2] result: Traceback (most recent call last): File "test_dftmagnitude.py", line 15, in <module> print "result:",dftmagnitude.spectrumMag(a) IndexError: Odd number of elements in input array: 3
~>
Regards, Egor
On Tue, Jan 6, 2009 at 1:06 AM, Rich E <reakinator@gmail.com> wrote:
Egor,
Thanks for the help. I think I want to leave the C code as-is however, as it is perfectly fine there no knowing 'sizeOutMag' because it can deduce both array sizes from one variable. There are many other similar cases in my code (many where the size of the array is known by a member of a structure passed to the function).
Maybe I should look into using an 'insertion block' of code in the interface file, instead of trying to typemap the array? I am thinking I may just be able to copy the generated code (from SWIG) into my interface file to do this, but I have not tried it yet.
I will experiment a little and post again. Thanks and happy holidays!
regards, Rich
On Mon, Jan 5, 2009 at 10:42 AM, Egor Zindy <ezindy@gmail.com> wrote:
Hello Rich,
sorry it took so long to answer back, holidays and all :-)
That's exactly the kind of SWIG / numpy.i problems I've been working on over the past few months: How to generate an array you don't know the size of a-priori, and then handle the memory deallocation seamlessly. In your case, you know that the output array will be half the size of the input array, but this falls under the more general case of "not knowing the output size a-priori".
Have a look at the files attached. I've rewritten your function header as: void sms_spectrumMag( int sizeInMag, float *pInRect, int *sizeOutMag, float **pOutMag);
Easy to see what the input and output arrays are now. Then my numpy.i handles the memory deallocation of the **pOutMag array.
I've actually moved my numpy.i explanations to the scipy/numpy cookbook last week :-) http://www.scipy.org/Cookbook/SWIG_Memory_Deallocation
Hope it all makes sense. If you have any questions, don't hesitate!
python test_dftmagnitude.py [1, 1, 2, 2] [ 1.41421354 2.82842708] [1, 1, 2, 2, 3, 3, 4, 4] [ 1.41421354 2.82842708 4.2426405 5.65685415] [1, 1, 2, 2, 3, 3, 4, 4, 5, 5] [ 1.41421354 2.82842708 4.2426405 5.65685415 7.07106781]
Regards, Egor
On Wed, Dec 24, 2008 at 1:52 AM, Rich E <reakinator@gmail.com> wrote:
Hi list,
My question has to do with the Numpy/SWIG typemapping system.
I recently got the typemaps in numpy.i to work on most of my C functions that are wrapped using SWIG, if they have arguments of the form (int sizeArray, float *pArray).
Now I am trying to figure out how to wrap function that aren't of the form, such as the following function:
/*! \brief compute magnitude spectrum of a DFT * * \param sizeMag size of output Magnitude (half of input real FFT) * \param pFReal pointer to input FFT real array (real/imag floats) * \param pFMAg pointer to float array of magnitude spectrum */ void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag) { int i, it2; float fReal, fImag;
for (i=0; i<sizeMag; i++) { it2 = i << 1; fReal = pInRect[it2]; fImag = pInRect[it2+1]; pOutMag[i] = sqrtf(fReal * fReal + fImag * fImag); } }
There are two arrays, one is half the size of the other. But, SWIG doesn't know this, according to the type map it will think *pInRect is of size sizeMag and will not know anything about *pOutMag.
Ideally in python, I would like to call the function as sms_spectrumMag(nArray1, nArray2), where nArray1 is twice the size of nArray2, and nArray2 is of size sizeMag.
I think in order to do this (although if someone has a better suggestion, I am open to it), I will have to modify the typemap in order to tell SWIG how to call the C function properly. I do not want to have to edit the wrapped C file every time it is regenerated from the interface file.
Here is a start I made with the existing typemap code in numpy.i (not working):
/* Typemap suite for (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) */ %typecheck(SWIG_TYPECHECK_DOUBLE_ARRAY, fragment="NumPy_Macros") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) { $1 = is_array($input) && PyArray_EquivTypenums(array_type($input), DATA_TYPECODE); } %typemap(in, fragment="NumPy_Fragments") (DIM_TYPE DIM1, DATA_TYPE* INPLACE_ARRAY1) (PyArrayObject* array=NULL, int i=0) { array = obj_to_array_no_conversion($input, DATA_TYPECODE); if (!array || !require_dimensions(array,1) || !require_contiguous(array) || !require_native(array)) SWIG_fail; $1 = 1; for (i=0; i < array_numdims(array); ++i) $1 *= array_size(array,i); $2 = (DATA_TYPE*) array_data(array); }
and try to alter it to allow for a conversion of type: (DIM_TYPE DIM1, DATA_TYPE* ARRAY1, DATA_TYPE* ARRAY2) where ARRAY1 is size DIM1 * 2 and ARRAY2 is size DIM1. Then I can %apply this to my function that I mentioned in the last post.
So here are my first two questions:
1) where is DIM1 used to declare the array size? I don't see where it is used at all, and I need to somewhere multiply it by 2 to declare the size of ARRAY1
2) I am not understanding where $input comes from, so I do not understand how to distinguish between ARRAY1 and ARRAY2. In the attempt I have already tried, I think I just use the pointer to ARRAY1 twice.
If anyone has suggestions on how to solve this problem, thanks!
regards, Rich _______________________________________________ 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

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

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

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

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

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?
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
* 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*
On Thu, Jan 8, 2009 at 2:13 AM, Egor Zindy <ezindy@gmail.com> wrote: thread). 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

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

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
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,
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
> 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
On Fri, Jan 9, 2009 at 7:05 AM, Egor Zindy <ezindy@gmail.com> wrote: this library 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
participants (3)
-
Egor Zindy
-
Matthieu Brucher
-
Rich E