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

Travis Oliphant oliphant.travis at ieee.org
Tue Aug 22 14:39:37 CDT 2006

Sebastian Haase wrote:
> Hi,
> I just ran into more problems with my SWIG
> typemaps.
> In the C api the current enum for 
> NPY_INT is 5 
> NPY_LONG is 7
> to match overloaded function I need to check these type values.
> On 64bit all works fine: 
> my 32bit int  function matches NPY_INT  - which is "int" in C/C++
> my 64bit int  function matches NPY_LONG  - which is "long" in C/C++
As you noted below, this is not always the case.  You can't assume that 
64-bit means "long"

Let me assume that you are trying to write functions for each of the 
"data-types".  You can proceed in a couple of ways:

1) Use the basic c-types
2) Use "bit-width" types (npy_int32, npy_int64, etc...)

The advantage of the former is that it avoids any confusion in terms of 
what kind of c-type it matches.  This is really only important if you 
are trying to interface with external code that uses basic c-types.

The advantage of the latter is that you don't have to write a redundant 
routine (i.e. on 32-bit linux the int and long routines should be 
identical machine code), but you will have to be careful in matching to 
a c-type should you need to call some external routine.

The current system gives you as many choices as possible (you can either 
match external code using the c-types) or you can write to a particular 
bit-width.  This is accomplished through comprehensive checks defined in 
the arrayobject.h file.


More information about the Numpy-discussion mailing list