[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux

Travis Oliphant oliphant.travis at ieee.org
Tue Aug 22 19:34:26 CDT 2006

Sebastian Haase wrote:
> This explains it - my specific function overloads only one of its two array 
> arguments (i.e. allow many different types)  - the second one must be a 
> C "int".    
> [(a 32bit int) - but SWIG  matches the "C signature" ] 
> But what is the type number of "<i4" ? It is: on 64bit I get NPY_INT.
> But on 32bitLinux I get NPY_LONG because of that rule.
> My SWIG typemaps want to "double check" that a C function expecting c-type 
> "int" gets a NPY_INT  - (a "long" needs a "NPY_LONG") 
Perhaps I can help you do what you want without making assumptions about 
the platform.   I'll assume you are matching on an int* signature and 
want to "translate" that to an integer array of the correct bit-width.  
So, you have a PyArrayObject as input I'll call self

Just check:

(PyArray_ISSIGNED(self) && PyArray_ITEMSIZE(self)==SIZEOF_INT)

For your type-map check.  This will work on all platforms and allow 
signed integers of the right type.

> I don't know what the solution should be  - but maybe the rule should be 
> changed based on the assumption that "int" in more common !?
That's not going to happen at this point.  Besides in the Python world, 
the fact that Python integers are "long" means that the "long" is the 
more common 32-bit integer on 32-bit machines.


More information about the Numpy-discussion mailing list