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