[SciPy-dev] numpy long vs. int
Fri Jul 25 17:45:59 CDT 2008
> On Fri, Jul 25, 2008 at 17:36, Damian Eads <email@example.com> wrote:
>> Hi there,
>> I had some problems porting some internal extension code I wrote
>> The code worked fine on 32-bit but did not work on 64-bit. When np.int_
>> used as the dtype argument to np.zeros or np.asarray, an array results
>> that has typecode NPY_INT on 32-bit and NPY_LONG on 64-bit. This
>> inconsistency is problematic when type checking arrays in C-space prior
>> passing them to a C function expecting a specific type, like int.
>> dtype=np.int_ to dtype='i' seems to consistently result in an array with
>> typecode NPY_INT on both architectures, which is desired.
>> I didn't think to write about this until I encountered the very same
>> problem today when trying to compile the ANN scikit on 64-bit. All the
>> tests failed because the kd-tree array passed was of type long.
>> 0.53209373, 0.2149725 ],
>> Traceback (most recent call last):
>> line 182, in runTest
>> line 49, in checkReturnNN
>> nn,nn_distances = tree.knn(pt,1)
>> File "scikits/ann/__init__.py", line 113, in knn
>> self._knn2(pts, idx, d2, eps)
>> File "scikits/ann/ANN.py", line 45, in _knn2
>> def _knn2(*args): return _ANN._kdtree__knn2(*args)
>> TypeError: Array of type 'int' required. Array of type 'long' given
>> Changing line 110 from dtype=np.int_ to dtype='i' fixed the problem.
>> people seem insistent on using a type object (e.g. np.int_ or np.float_)
>> instead of a string. In fact, when I checked in my hierarchical
>> code, I noticed someone eventually changed all the dtype's in my code to
>> use the type objects. I had no qualms with this until now. Are there
>> objects that can be passed to dtype to guarantee consistency in
>> translation to NPY_XXX type codes? We should probably write a caveat in
>> the Numpy C extensions help document explaining this inconsistency.
> numpy.intc gives NPY_INT. numpy.int_ gives NPY_LONG (since Python ints
> are C longs).
Any reason why there aren't np.floatc or np.doublec equivalents?
More information about the Scipy-dev