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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
