🚀 go-pugleaf

philip@cs.vu.nl (Philip Homburg) wrote:
>In article <40rjdn$jof@solutions.solon.com>,
>Peter Seebach <seebs@solutions.solon.com> wrote:
>%How are we to test this?  There exists (on at least one machine) at least
>%one float greater than INT_MAX which compares less than (float) INT_MAX;
>%in particular, on a 68000 system I use, INT_MAX is 2147483647, but
>%(float) INT_MAX is 2147483648.  So, 2147483647.5 would compare less
>%than INT_MAX, but would (in fact) be too large.

>I don't understand this. If 2147483647.5 and 2147483648 are both values that
>can be represented exactly by a variable of type float, then why do you convert
>the integer 2147483647 to the float 2147483648.0 since 2147483647.5 would
>be closer to 2147483647?
>Are you sure that a float can represent the value 2147483647.5?

You're seeing an artifact.  IEEE floats have 23 bits of precision, while
the INT_MAX value cited is obviously for a 2's complement 32 bit word.  
Thus, the largest integer that an IEEE float can be represent in sequence 
is 8,388,607.  Other, larger integers can be represented exactly, but they
must have all the '1' bits in the high-order 23.

Since INT_MAX+1 falls into the latter catagory, a float can exactly 
represent it, and you're seeing implementation-dependent behaviour.

Try it with a double and you get the results you'd expect, since a double
has 52 bits of precision.