Whats wrong with this simple ‘double’ calculation? [duplicate]

The problem

In binary 2.64 is 10.10100011110101110000101000111101 recurring, in other words not exactly representable in binary, hence the small error. Java is being kind to you with d3 but as soon as actual calculations are involved it has to fall back on the real representation.

Binary Calculator

Further more:

2.64= 10.10100011110101110000101000111101
4.64=100.1010001111010111000010100011110 

Now, even though the .64 is the same in both cases, it is held to different precisions because the 4=100 uses up more of the double significant figures than 2=10, so when you say 4.64-2.0 and 2.64 the .64 is represented with a different rounding error in both cases, this lost information cannot be recovered for the final answer.

N.B. I’m not using the double number of significant figures here, just whatever the binary calculator would produce, however the effect is the same whatever the number of significant figures

Never assume double values are exact (although their inaccuracies are microscopic and caused only because certain numbers can’t be exactly expressed in binary).

Floating point numbers aren’t exact, but only from a decimal point of view

While you should always expect that doubles will have small errors for the last few decimal places it would be wrong to think of binary representations as “bad” or worse that decimal.

We are all used to certain numbers (like 1/3 for example) not being exactly representable in decimal and we accept that such a number will end up as 0.333333333333 rather than the true value (which I cannot write down without infinite space); it is within that context that binary numbers cannot be exactly expressed. 1/10 is such a number that cannot be exactly expressed in binary; this suprises us only because we are used to decimal

Leave a Comment