[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.
-Travis
More information about the Numpy-discussion
mailing list