I agree that doing them as if usin infinite precision is best, but I adamantly oppose the idea that they should not be comparable at all.

As do I.

To the contrary, we should do our best to ensure that int/long are properly and cleanly embedded in floats. That's why I introduced the change to int/long division after all.

Agreed.

Unfortunately, long/float comparison doesn't work quite correctly right now:

n = 1 for i in range(2000): n += n n == 0.0

OverflowError: long int too large to convert to float

One strategy for solving the problem is to observe that for every floating-point implementation, there is a number N with the property that if x >= N, converting x from float to long preserves information, and if x <= N, converting x from long to float preserves information. Therefore, instead of unconditionally converting to float, the conversion's direction should be based on the value of one of the comparands.

Of course, such comparisons can be made faster by doing a rough range check first, and doing the actual conversion only if the number of bits in the long is commensurate with the exponent of the float.