[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
oliphant.travis at ieee.org
Tue Aug 22 14:39:37 CDT 2006
Sebastian Haase wrote:
> I just ran into more problems with my SWIG
> 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