[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?
It would help if you were explicit about what you think "the error"
is. I see a correct result in all cases there.
Is it just that sometimes
int(a_float)
returns a Python long when
int(a_long_with_the_same_value_as_that_float)
returns a Python int? If so, that's not a bug -- there's no promise
anywhere, e.g., that Python will return an int whenever it's
physically possible to do so.
Python used to return a (short) int in all cases above, but that lead
to problems on some oddball systems. See the comments for float_int()
in floatobject.c for more detail. Slowing float_int() to avoid those
problems while returning a short int whenever physically possible is a
tradeoff I would oppose.
--
http://mail.python.org/mailman/listinfo/python-list
