[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
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
(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