I am using Dev C++ IDE.
the following if block executes to true I need ot know why???
float c=0.6;
if(c>0.6)
printf("A");
else printf("b");

Output=A
Plz i need to know why the if condition is true.I already know that any decimal constant is treated as a double in C but how does that apply here?????
Comparison between double and float
Page 1 of 15 Replies  404 Views  Last Post: 05 March 2011  11:01 AM
Replies To: Comparison between double and float
#2
Re: Comparison between double and float
Posted 05 March 2011  09:48 AM
Try adding a f behind the number you want compared, to cast it to float.
if (c > 0.6f)
This post has been edited by Atli: 05 March 2011  09:50 AM
#3
Re: Comparison between double and float
Posted 05 March 2011  09:49 AM
#4
Re: Comparison between double and float
Posted 05 March 2011  09:55 AM
#5
Re: Comparison between double and float
Posted 05 March 2011  09:57 AM
O, sorry. So used to people asking for a solution rather than a reason
I'm not 100% sure why it's evaluated as higher (math is not my thing), but I suspect it has to do with how the fractions are rounded. Floating point values are not 100% precise  something to do with the way they are stored (see here)  so I can only assume that 0.6 as a double is stored as fractionally larger than the 0.6 float.
In practice it is generally not a good idea to assume floating point numbers of different types are accurate to the point that == will evaluate as true. Better to deal in ranges when that is the case.
I'm not 100% sure why it's evaluated as higher (math is not my thing), but I suspect it has to do with how the fractions are rounded. Floating point values are not 100% precise  something to do with the way they are stored (see here)  so I can only assume that 0.6 as a double is stored as fractionally larger than the 0.6 float.
In practice it is generally not a good idea to assume floating point numbers of different types are accurate to the point that == will evaluate as true. Better to deal in ranges when that is the case.
#6
Re: Comparison between double and float
Posted 05 March 2011  11:01 AM
Atli, on 05 March 2011  11:57 AM, said:
O, sorry. So used to people asking for a solution rather than a reason
I'm not 100% sure why it's evaluated as higher (math is not my thing), but I suspect it has to do with how the fractions are rounded. Floating point values are not 100% precise  something to do with the way they are stored (see here)  so I can only assume that 0.6 as a double is stored as fractionally larger than the 0.6 float.
In practice it is generally not a good idea to assume floating point numbers of different types are accurate to the point that == will evaluate as true. Better to deal in ranges when that is the case.
I'm not 100% sure why it's evaluated as higher (math is not my thing), but I suspect it has to do with how the fractions are rounded. Floating point values are not 100% precise  something to do with the way they are stored (see here)  so I can only assume that 0.6 as a double is stored as fractionally larger than the 0.6 float.
In practice it is generally not a good idea to assume floating point numbers of different types are accurate to the point that == will evaluate as true. Better to deal in ranges when that is the case.
The issue here isn't really about double vs float, although double storage will certainly permit much greater precision... As both the above provided links point out, the problem all has to do with the fact that numbers are stored as binary bits of code. If the memory for a number is, say 32 bits, how many different numbers can be coded? As long as the numbers you are using are integers, within the range allowed by the number of bits to hold those numbers, exact comparison of numbers is ok. But if the number is a decimal approximation to a certain real value, numbers can only be compared up to the limits of that approximation.
You may think of this, similarly to a scientific measurement to so many significant digits ... Say the limits of precision of measurement were 3 sig.figures.
Now you make measurements ... (estimated as)
1. 7.355
2. 7.357
3. 7.345
...
The first 2 above are really the same ... 7.36 + 0.005
The 3rd, 7.35, you can only say was about 0.01+ 0.005 smaller
This post has been edited by David W: 05 March 2011  11:22 AM
Page 1 of 1
