Int32s, scalar operations and Pyhon longs

Tim Hochberg tim.hochberg at ieee.org
Thu Nov 9 11:00:57 CST 2006


Robert Kern wrote:
> Fernando Perez wrote:
>   
>> I understand why this happens, but I wonder if it should be in any way
>> 'fixed' (if that is even feasible without introducing other problems):
>>
>> In [28]: x = 999999
>>
>> In [29]: y = numpy.array([x])
>>
>> In [30]: z = y[0]
>>
>> In [31]: x==z
>> Out[31]: True
>>
>> In [32]: x
>> Out[32]: 999999
>>
>> In [33]: z
>> Out[33]: 999999
>>
>> In [34]: x*x
>> Out[34]: 999998000001L
>>
>> In [35]: z*z
>> Warning: overflow encountered in long_scalars
>> Out[35]: -729379967
>>
>> I am sure it will be, to say the least, pretty surprising (and I can
>> imagine subtle bugs being caused by this).
>>     
>
> I think we decided long ago that an int32 really is an array of 32-bit integers
> and behaves like one. That's precisely why one uses int32 arrays rather than
> object arrays. There are algorithms that do need the wraparound, and the Python
> int behavior is always available through object arrays.
>
>   
Let me add that I can't imagine that the bugs will be all that subtle 
given that numpy now spits out a warning on overflow.
If you're really worried about this I suggest you crank up the error 
mode to make this an error - then you really won't be able to miss this 
kind of overflow.

-tim




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642




More information about the Numpy-discussion mailing list