[Numpy-discussion] Conversion float64->int bugged?
Tue Jul 10 12:08:49 CDT 2007
On 7/9/07, Xavier Saint-Mleux <email@example.com> wrote:
> Hi all,
> The conversion from a numpy scalar to a python int is not consistent
> with python's native conversion (or numarray's): if the scalar is out
> of bounds for an int, python and numarray automatically create a long
> while numpy still creates an int... with the wrong value.
> N.B. I am new to numpy, so please forgive me if this issue has already
> been discussed. I've quickly searched the archives and Travis's "Guide
> to NumPy", with no success.
> e.g. (using numpy 1.0.3):
> Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from numpy import *
> >>> l= [1e3, 1e9, 1e15, -1e3, -1e9, -1e15]
> >>> a= array(l)
> >>> map(int, l)
> [1000, 1000000000, 1000000000000000L, -1000, -1000000000,
> >>> map(int, a)
> [1000, 1000000000, -2147483648, -1000, -1000000000, -2147483648]
> >>> map(long, a)
> [1000L, 1000000000L, 1000000000000000L, -1000L, -1000000000L,
> IMHO, numpy's conversions to int should behave like Python's 'float_int'
> or 'long_int' functions (see $PYTHON_SRC_DIR/Objects/floatobject.c,
> $PYTHON_SRC_DIR/Objects/longobject.c): if it doesn't fit in an int,
> return a long. For now (svn), it seems that numpy is always using
> PyInt_FromLong after an implicit C cast to long (which silently fails;
> see $NUMPY_SRC_DIR/numpy/core/src/scalarmathmodule.c.src)
> Is there any reason not to change this?
FWIW, it seems like a good idea to me.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion