[SciPy-dev] numpy long vs. int

[Robert Kern]

On Fri, Jul 25, 2008 at 17:36, Damian Eads <eads at soe.ucsc.edu> wrote:
> Hi there,
>
> I had some problems porting some internal extension code I wrote recently.
> The code worked fine on 32-bit but did not work on 64-bit. When np.int_ is
> 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 to
> passing them to a C function expecting a specific type, like int. Changing
> 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.
>
> ======================================================================
> ERROR: test_ann.TestANNWrapper.test_knn_returns_nearest_neighbor(array([[
> 0.53209373,  0.2149725 ],
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File
> "/mirror/ssrc/eads/sci-tools/prefix-x86-64/lib/python2.5/site-packages/nose-0.10.3-py2.5.egg/nose/case.py",
> line 182, in runTest
>    self.test(*self.arg)
>  File
> "/mirror/ssrc/eads/sci-tools-source/x86-64/ann/scikits/ann/tests/test_ann.py",
> 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. Some
> 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 clustering
> 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 type
> 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).

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco