[Numpy-tickets] [NumPy] #370: oldnumeric.Int32 mapping on 32-bit platforms seems wrong

[NumPy]

#370: oldnumeric.Int32 mapping on 32-bit platforms seems wrong
-----------------------+----------------------------------------------------
 Reporter:  faltet     |        Owner:  somebody
     Type:  defect     |       Status:  closed  
 Priority:  normal     |    Milestone:          
Component:  numpy.lib  |      Version:  devel   
 Severity:  normal     |   Resolution:  wontfix 
 Keywords:             |  
-----------------------+----------------------------------------------------
Comment (by faltet):

 Mmm, I don't think this problem is related with 64-bit at all. The source
 of the problem is the next code in

 http://projects.scipy.org/scipy/scipy/browser/trunk/Lib/ndimage/Src/ni_measure.c?rev=1731

 {{{
 #!c

     for(jj = 0 ; jj < size; jj++) {

         switch (input->descr->type_num) { CASE_FIND_OBJECT_POINT(pi,
 regions, input->nd, input->dimensions,

             max_label, ii, Bool);

         CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

             max_label, ii, UInt8);

         CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

             max_label, ii, UInt16);

         CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

             max_label, ii, UInt32);

 #if HAS_UINT64

     CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

         max_label, ii, UInt64);

 #endif

     CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

         max_label, ii, Int8);

     CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

         max_label, ii, Int16);

     CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

         max_label, ii, Int32);

     CASE_FIND_OBJECT_POINT(pi, regions, input->nd, input->dimensions,

         max_label, ii, Int64);

     break;

     default:

         PyErr_SetString(PyExc_RuntimeError, "data type not supported");
 goto exit;

     }

 }}}

 In that code, there is a check for every Int8,... UInt64 !NumPy types. The
 problem is that if you create an array as a 'intc' (like it happens with
 oldnumeric.Int32), it is mapped to NPY_INT (i.e. a 5 in NPY_TYPES), but
 NPY_INT32 is mapped to NPY_LONG in 32-bit machines (i.e. a 7 in
 NPY_TYPES). As NPY_INT and NPY_LONG are not the same type, the switch
 doesn't catch a type called NPY_INT, even though you check for the
 complete range Int8..UInt64 because NPY_INT is not mapped to any of them.

 I think this is a general problem with the current type definition in
 !NumPy, and should be adressed in a way or another. Or perhaps I'm biased,
 and the above kind of checks is not correct (although I tend to think that
 it can be very very common for extension programmers).

 Just my 2 cents

-- 
Ticket URL: <http://projects.scipy.org/scipy/numpy/ticket/370#comment:4>
NumPy <http://projects.scipy.org/scipy/numpy>
The fundamental package needed for scientific computing with Python.