## Interview Question

- 0of 0 votes
Explain the output :

#include<stdio.h>

int main()

{ double i=0;

i+=0.1;

i+=0.1;

i+=0.1;

i+=0.1;

i+=0.1;

i+=0.1;

i+=0.1;

if(i==0.7)

printf("Equal : i=0.7\n");

i+=0.1;

if(i==0.8) printf("Equal : i=0.8\n");

else printf("Not Equal : i=0.8\n");

return 0;

}

**Country:**United States

I've executed this program on gcc and also on dev c++ .

and changing double to float , still give me the same answer .

Getting output : Equal : i=0.7

Not Equal : i=0.8

Why is it so ?

No I've executed it on gcc by replacing double to float it is giving only "Not Equal : i=0.8" as output,plz check once again

Here

if( i == 0.7) //here i is double and 0.7 gets type caste from float to double

if(i==0.8) // here i is double and 0.8 also gets type caste as above so in both case it should print Not Equal.

Am i correct?

*You cannot compare 2 floats or doubles using == *

Floats and doubles are by their nature imprecise, and doing arthmetic with them causes them to have what's known as roundoff error. 0.1 * 7 may be 0.69999993427 or 0.700000000003482, and thus not equal to 0.7. And 0.1 * 7 is not the same as 0.1 + 0.1 + 0.1 + ... + 0.1 7 times. And for given a, b, c, a+b+c may differ from a+c+b. Perhaps an even more appalling thing is that it's even possible that if you do x=0.1 +0.1; y = 0.1 + 0.1 and then compare x==y later, they may or may not be different!

So is C broken? No. Just don't compare imprecise types with precise comparisons. Instead, always use this style of comparisons:

Const double epsilon = 1e-6; // for example

If (abs(x-y) < epsilon ) { consider them equal; }

Thanks for the elaborate answer

how is that for

if( i == 0.7) //Prints Equal

and

if(i==0.8) //Prints UnEqual

Who knows. Maybe the roundoff errors cancel out just right. Point is that you're doing something you're not supposed to by comparing imprecise types with ==, and as a result, the output is difficult to predict.

Very rightly said. I would also like to add some food for thought.

The actual values that are being stored are not the one being passed, rather they are stores in the form of exponent & mantissa, they get silently rounded off to the approximated values

because of the recurring nature of the binary form being converted. Also,it depends on the architecture, whether the intermediate values are stored somewhere[more likely to get the approximated or rounded values] or the directly used to get the result. Hence a+b+c is different from a+c+b.

What shondik is saying is that the hardware doesn't even have any way of representing 0.1 exactly. Since the representation is in what is similar to binary scientific notation (think 1.23434 E +5, that kind of thing, but in binary), things like 0.1 in decimal may actually be nonterminating decimals in binary. Since these binary decimals can only be stored at some finite level of precision, you basically incur roundoff error simply by storing a number.

This reminds me of a Saturday Morning Breakfast Cereal comic:

the reason getting output as "Not Equal : i=0.8 " is that we cant compare float/double as i==0.7. reason is that 0.7 is a constant and i being a float or double would have value as 0.700000 and similarly double i ll have the trailing zeros. this makes them not equal to each other and results in false value.

output :

- Siva Krishna on July 06, 2012 Edit | Flag ReplyEqual : i=0.7

Equal : i=0.8

why because here i==0.7 "0.7" is taken as double and 'i' is also double so it is true,but if we take 'float i' then it is false.