[Numpy-discussion] Question about bounds checking
Dear all, I am having a few issues with indexing in numpy and wondered if you could help me out. If I define an array a = zeros(( 4)) a array([ 0., 0., 0., 0.]) Then I try and reference a point beyond the bounds of the array a[4] Traceback (most recent call last): File "", line 1, in IndexError: index out of bounds but if I use the slicing format to reference the point I get a[0:4] array([ 0., 0., 0., 0.]) a[0:10] array([ 0., 0., 0., 0.]) it returns a[ 0 : 3 ], with no error raised. If I then ask for the shape of the array, I get a.shape (4,) but if I use a[0:3].shape (3,) which is one less than I would have expected. a[0:4].shape (4,) This is numpy 1.2.1 on python 2.5 Thanks in advance for you help, Rich ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] default float type of array not accepted by SWIG wrapped C functions
I ended up solving my problem in SWIG, so I might as well post it
here. I just made my own 'array' and 'zeros' functions with floating
point precision as follows:
%pythoncode %{
from numpy import array as np_array
def array (n, type='float32'):
return(np_array(n, type))
from numpy import zeros as np_zeros
def zeros (n, type='float32'):
return(np_zeros(n, type))
%}
Pretty basic, I know. But it cuts down on alot of unnecessary code.
- Rich
On Thu, Jan 22, 2009 at 6:09 PM, Spotz, William F wrote:
> Rich,
>
> Basic python only supports double precision floats, so that is not an option.
>
> NumPy does not have, as far as I know, a way to set the default precision,
> although it might be a reasonable request.
>
> As for the SWIG interface file, almost anything is possible. Can you give an
> example of a function prototype you are wrapping, the %apply directive you
> use and and example of python code accessing it?
>
> -Bill
>
> From: numpy-discussion-boun...@scipy.org [numpy-discussion-boun...@scipy.org]
> On Behalf Of Rich E [reakina...@gmail.com]
> Sent: Thursday, January 22, 2009 11:45 AM
> To: Discussion of Numerical Python
> Subject: [Numpy-discussion] default float type of array not accepted by SWIG
> wrapped C functions
>
> Hi all,
>
> I have a SWIG wrapped C library that uses 32bit floating point arrays,
> using the numpy.i typemapping system for passing the arrays. For
> every array that I make, I have to convert it using astype('float32'),
> else python complains that I tried to pass a double-precision array.
>
> Is there any way to set the default floating point precision to 32bit,
> in python or in the SWIG interface file?
>
> 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
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] default float type of array not accepted by SWIG wrapped C functions
Hi all,
I have a SWIG wrapped C library that uses 32bit floating point arrays,
using the numpy.i typemapping system for passing the arrays. For
every array that I make, I have to convert it using astype('float32'),
else python complains that I tried to pass a double-precision array.
Is there any way to set the default floating point precision to 32bit,
in python or in the SWIG interface file?
regards,
Rich
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] help with typemapping a C function to use numpy arrays
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 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 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 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 wrote: >> >> >> >> Here is my example, trying to wrap the function sms_spectrumMag that >> >> we have been dealing with: >> >> >&
Re: [Numpy-discussion] help with typemapping a C function to use numpy arrays
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 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 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
>> wrote:
>> > 2009/1/6 Rich E :
>> >> 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 Eng
Re: [Numpy-discussion] help with typemapping a C function to use numpy arrays
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
wrote:
> 2009/1/6 Rich E :
>> 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
Re: [Numpy-discussion] help with typemapping a C function to use numpy arrays
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 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 > 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 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 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.414
Re: [Numpy-discussion] help with typemapping a C function to use numpy arrays
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 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 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 pFMAgpointer 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> {
>> 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)
>> {
&
[Numpy-discussion] 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 pFMAgpointer to float array of magnitude spectrum
*/
void sms_spectrumMag( int sizeMag, float *pInRect, float *pOutMag)
{
int i, it2;
float fReal, fImag;
for (i=0; ihttp://projects.scipy.org/mailman/listinfo/numpy-discussion
