[Numpy-tickets] [NumPy] #370: oldnumeric.Int32 mapping on 32-bit platforms seems wrong
NumPy
numpy-tickets at scipy.net
Thu Nov 2 14:01:40 CST 2006
#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.
More information about the Numpy-tickets
mailing list