IEEE 754：Javascript vs C

Question

From what I understand, the famous

 (0.1 + 0.2) !== 0.3

gotcha is not actually Javascript's fault. Thats just the way the IEEE 754 works. A similar output happens in Python, which also follows the IEEE 754 rules.

Then how come this particular example works as expected in C, sometimes . If I do a direct comparison

printf("%d\n", (0.1+0.2) == 0.3);

I get the (un?)expected output 0 , but if I put the values into variables or print them out, I get properly rounded answers.

C Runnable Example

Is the C implementation of IEEE 754 doing something extra? Or is it something completely else that I am missing.

Update

The code sample I posted was broken due to a typo. Try this one Fixed C Runnable Example

But the original Question still remains.

double d1, d2, d3;
d1 = 0.1;    d2 = 0.2;    d3 = d1 + d2;
printf ("%d\n", ((((double)0.1)+((double)0.2)) == ((double)d3)));
printf ("%.17f\n", d1+d2);
printf ("%d\n", ((d1+d2) == d3));

The output is

1
0.30000000000000004
1

The rephrased question now is:

1. Why (and when, and how) is the C compiler taking the liberty to say that

   0.3 == 0.30000000000000004

2. Given all facts, isn't it true that the C implementation is broken, rather than Javascripts'?

Answer 1

Why (and when, and how) is the C compiler taking the liberty to say that

  0.3 == 0.30000000000000004 

Given all facts, isn't it true that the C implementation is broken, rather than Javascripts'?

It isn't.

The output given is from this code:

printf ("%d\n", ((((double)0.1)+((double)0.2)) == ((double)d3)));

but you wrote:

d1 = 0.1;    d2 = 0.2;    d3 = d1 + d2;

so d3 is not 0.3 , it's 0.30000000000000004

Answer 2

`printf("%d\n", (0.1+0.2) == 0.3);`

These are DOUBLEs not FLOATs.

Do:

printf("%d\n", (0.1+0.2) == 0.3);
printf("%d\n", (0.1f+0.2f) == 0.3f);

and voila!

http://codepad.org/VF9svjxY

Output:
0
1

Check out this question. It's about smth else, but ppl using GCC got different results than ppl with MSVC. printing the integral part of a floating point number

Answer 3

Your example code uses 1, 2 and (1+2), which are all exactly representable in double precision floating point. 0.1 on the other hand is NOT exactly representable in floating point and thus you get an approximation to this number. When adding approximately 0.1 to approximately 0.2 you will get approximately 0.3, but whether that's going to be EXACTLY the same approximation that a compiler would choose when representing 0.3 who can tell.

The representation is using binary. Which means it uses 1/2, 1/4, 1/8, 1/16, 1/32 (and so on to a number of precision ....). This means that 0.5, 0.25 etc are exactly able to be represented. Numbers that aren't an exact sum of binary fractions can be approximated very closely.

Solution: don't compare floating point numbers to each other. Compare their difference to some small number that you don't care about.

#define EPSILON 0.000001
printf("%d", fabs((0.1+0.2) - 0.3 ) < EPSILON );

I'm not sure why the C code works and the python/javascript doesn't. It's magic. But hopefully this answers your question anyway.