[Numpy-discussion] SWIG wrappers: Inplace arrays

[Travis Oliphant]

Albert Strasheim wrote:

>Hello all
>
>I am using the SWIG Numpy typemaps to wrap some C code. I ran into the
>following problem when wrapping a function with INPLACE_ARRAY1.
>
>In Python, I create the following array:
>
>x = array([],dtype='<i4')
>
>When this is passed to the C function expecting an int*, it goes via
>obj_to_array_no_conversion in numpy.i where a direct comparison of the
>typecodes is done, at which point a TypeError is raised.
>
>In this case:
>
>desired type = int [typecode 5]
>actual type = long [typecode 7]
>
>The typecode is obtained as follows:
>
>#define array_type(a) (int)(((PyArrayObject *)a)->descr->type_num)
>
>Given that I created the array with '<i4', I would expect type_num to map to
>int instead of long. Why isn't this happening?
>  
>
Actually there is ambiguity i4 can be either int or long.   If you want 
to guarantee an int-type then use
dtype=intc).

>Assuming the is a good reason for type_num being what it is, I think
>obj_to_array_no_conversion needs to be slightly cleverer about the
>conversions it allows. Is there any way to figure out that int and long are
>actually identical (at least on my system) using the Numpy C API? Any other
>suggestions or comments for solving this problem?
>
>  
>
Yes.  You can use one of

PyArray_EquivTypes(PyArray_Descr *dtype1, PyArray_Descr *dtype2)
PyArray_EquivTypenums(int typenum1, int typenum2)
PyArray_EquivArrTypes(PyObject *array1, PyObject *array2)

These return TRUE (non-zero) if the two type representations are equivalent.

-Travis