[Numpy-tickets] [NumPy] #549: int() of numpy scalar fails silently

[NumPy]

#549: int() of numpy scalar fails silently
------------------------+---------------------------------------------------
 Reporter:  zouave      |       Owner:  somebody
     Type:  defect      |      Status:  new     
 Priority:  normal      |   Milestone:          
Component:  numpy.core  |     Version:  devel   
 Severity:  major       |    Keywords:          
------------------------+---------------------------------------------------
 [posted on numpy-discussion on 2007-07-09]

 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.

 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,
 -1000000000000000L]
  >>> map(int, a)
 [1000, 1000000000, -2147483648, -1000, -1000000000, -2147483648]
  >>> map(long, a)
 [1000L, 1000000000L, 1000000000000000L, -1000L, -1000000000L,
 -1000000000000000L]
  >>>
 }}}

 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)

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