0.1 + 0.2 != 0.3 revisited
Hi, IEEE says that real numbers are normalized (a few below 10^(-16) may be not [gradual underflow]), so that they look like 0.1ddd2^ex. Then only ddd and ex are kept: 0.1 = 0.00011.. 2^0 = 0.11001100.. 2^(-3) -> (11001100.., -3) 0.2 = 0.0011.. 2^0 = 0.11001100.. 2^(-2) -> (11001100.., -2) 0.3 = 0.010011..2^0 = 0.10011001.. 2^(-1) -> (10011001.., -1)
Duncan Murdoch wrote:
On Fri, 6 Feb 2004 12:55:05 -0000, "Simon Fear" <Simon.Fear at synequanon.com> wrote :
Prompted by Peter Dalgard's recent elegant "intbin" function,
I have been playing with the extension to converting reals to binary
representation. The decimal part can be done like this:
decbase <- function(x, n=52, base=2) {
if(n) {
x <- x*base
paste(trunc(x), decbase(x%%1, n-1, base), sep="")
}
}
n=52 default because that's the number of bits in the significand of
a 64-bit float.
Remember that IEEE double formats are complicated, they're not fixed point formats. Both 0.1 and 0.2 are less than 1, so the n=52 count is wrong. I think 0.1 would be stored as (1 + 0.6)*2^(-4) and 0.2 would be stored as (1 + 0.6)*2^(-3), whereas 0.3 would be stored as (1 + 0.2)*2^(-2). You should expect 56 decimal (binary?) place accuracy on 0.1, 55 place accuracy on 0.2, and 54 place accuracy on 0.3. It's not surprising weird things happen!
I don *not* think so: all mantissas here have *52 binary* places!
Duncan Murdoch
Christian Hoffmann
Dr.sc.math.Christian W. Hoffmann, http://www.wsl.ch/staff/christian.hoffmann Mathematics + Statistical Computing e-mail: hoffmacw at wsl.ch Swiss Federal Research Institute WSL Tel: ++41-1-73922.. ..77 (self) CH-8903 Birmensdorf, Switzerland ..11(exchange), ..15 (Fax)