Xref: utzoo comp.lang.prolog:3048 comp.lang.c:31101
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!leah!bingvaxu!vu0310
From: vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.lang.prolog,comp.lang.c
Subject: Re: Fun With Floats in Quintus
Message-ID: <3836@bingvaxu.cc.binghamton.edu>
Date: 14 Aug 90 17:24:13 GMT
References: <EIVERSON.90Aug13174424@aigyptos.nmsu.edu> <3829@bingvaxu.cc.binghamton.edu> <1990Aug14.034632.5561@twinsun.com>
Reply-To: vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell)
Organization: SUNY Binghamton, NY
Lines: 19

In article <1990Aug14.034632.5561@twinsun.com> eggert@twinsun.com (Paul Eggert) writes:
>with IEEE double precision floating point, the closest representable number to
>8.1 is X = 8.0999999999999996447286321199499070644378662109375.  But when I

While my sun and sparc came up with the same rep as you(rs),
I don't think it is the *closest* one to 8.1 in 55 bits of mantissa.

Since 8.1 is hex 81[9's]8 where the lsb of "8" is the 56th bit,
it rounds up (since the next bits after the 55th are 1100) to
81[9's]a which gives:

8.100000000000000088817841970012523233890533447265625

[I became sus when my vax gave 8.1[0's]1 for a double 8.1].

Maybe a few C printf's need overhaul, besides the point of rounding
to the nearest number in significant decimal digits.

-Kym Horsell