integral to floating point conversion

[Observer via Digitalmars-d]

On Sunday, 3 July 2016 at 13:41:27 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 3 July 2016 at 11:49:15 UTC, Andrei Alexandrescu 
> wrote:
>> Well to be more precise here's what I'm looking for. When you 
>> compare an integral with a floating point number, the integral 
>> is first converted to floating point format. I.e. for long x 
>> and double y, x == y is the same as double(x) == y.
>>
>> Now, say we want to eliminate the "bad" cases of this 
>> comparison. Those would make it non-transitive. Consider two 
>> distinct longs x1 and x2. If they convert to the same double 
>> y, then x1 == y and x2 == y are true, which is contradictory 
>> with x1 != x2.
>
> If you assume round-to-even rounding mode then you get unique 
> representations for integers in the ranges as other people have 
> suggested:
>
> int_to_float : [-((1<<24)-1) , (1<<24)-1]
>
> int_to_double : [-((1<<53)-1) , (1<<53)-1]

Seems to me there are some assumptions being made here that
only the permanent storage bits are in play.  You've covered
the implicit leading bit, but what about possible guard digits,
depending on where the values are currently located in the
hardware?  Not that I've thought it through, but it's something
to think about.