On 2020-03-04 00:58, Tim Peters wrote:
[Guido]
But beware, IIRC there are pathological cases involving floats, (long) ints and rounding where transitivity may be violated in Python (though I believe only Tim Peters can produce an example :-).
Not anymore ;-) That is, while comparisons mixing bigints and floats may have suffered rounding surprises long ago, all cases of float-or-int compared-to float-or-int now act as if infinite precision were used. You can throw fractions.Fraction and (I believe) decimal.Decimal into that too. Except for NaNs in the floating types, there's a well-behaved total ordering now (whether doing mixed-type or intra-type comparisons).
That doesn't make it surprise-free, though. For example, just last week someone on bugs.python.org flipped out ;-) upon learning
10**100 == 1e100
False
10**100 < 1e100
True
Because, indeed, they don't denote the same "mathematical" value:
int(1e100)
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104
hex(_)
'0x1249ad2594c37d0000000000000000000000000000000000000000000000000000000000000000000000'
(1e100).hex()
'0x1.249ad2594c37dp+332'
In the Ada programming language, 1e100 is an integer, whereas 1.0e100 is a float, so if Python has done that example, 10**100 == 1e100 would indeed be True.