[BUG] IMO, but no opinions? Uncle Tim? was: int(float(sys.maxint)) buglet ?

[Bengt Richter]

Peculiar boundary cases:

 >>> 2.0**31-1.0
 2147483647.0
 >>> int(2147483647.0)
 2147483647L
 >>> int(2147483647L )
 2147483647
 >>>
 >>> -2.0**31
 -2147483648.0
 >>> int(-2147483648.0)
 -2147483648L
 >>> int(-2147483648L )
 -2147483648

some kind of one-off error? I.e., just inside extremes works:

 >>> [int(x) for x in (-2.0**31, -2.0**31+1.0, 2.0**31-2.0, 2.0**31-1.0)]
 [-2147483648L, -2147483647, 2147483646, 2147483647L]

But those longs at the extremes can be converted successfully, so int(int(x)) works ;-/

 >>> [int(int(x)) for x in (-2.0**31, -2.0**31+1.0, 2.0**31-2.0, 2.0**31-1.0)]
 [-2147483648, -2147483647, 2147483646, 2147483647]

ISTM this is a buglet, or at least a wartlet for a 32-bit system ;-)

Almost forgot:
Python 2.4b1 (#56, Nov  3 2004, 01:47:27)
[GCC 3.2.3 (mingw special 20030504-1)] on win32

but same thing on 2.3.2:

 Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 >>> [int(x) for x in (-2.0**31, -2.0**31+1.0, 2.0**31-2.0, 2.0**31-1.0)]
 [-2147483648L, -2147483647, 2147483646, 2147483647L]
 >>> [int(int(x)) for x in (-2.0**31, -2.0**31+1.0, 2.0**31-2.0, 2.0**31-1.0)]
 [-2147483648, -2147483647, 2147483646, 2147483647]

Hm, ... except for the thought that CPUs with 64-bit integers might truncate maxint
when converting to float, I might say maybe these reprs should be tested
for equality in the system tests?

 >>> import sys
 >>> repr(int(float(sys.maxint))),  repr(sys.maxint)
 ('2147483647L', '2147483647')
 >>> repr(int(float(-sys.maxint-1))),  repr(-sys.maxint-1)
 ('-2147483648L', '-2147483648')

or maybe at least check for equality of these?:

 >>> type(int(float(sys.maxint))),  type(sys.maxint)
 (<type 'long'>, <type 'int'>)
 >>> type(int(float(-sys.maxint-1))),  type(-sys.maxint-1)
 (<type 'long'>, <type 'int'>)

Regards,
Bengt Richter