2
float f=2.2;
if (f==2.2)
printf("abc");
else
printf("xyz");

This code prints xyz,while if we give 2.5 instead of 2.2 the output is abc.

Deya
  • 47
  • 3
  • Floating-point numbers are [likely to contain round-off](http://www.cs.yale.edu/homes/aspnes/pinewiki/C(2f)FloatingPoint.html) error – Irf Feb 03 '17 at 05:40

2 Answers2

7

2.2 is a double that is not exactly representable in binary floating point. In effect, you are comparing the double 2.2 to the result of converting it to float, with rounding, and then back to double.

Assuming double is IEEE 754 64-bit binary floating point, and float is IEEE 754 32-bit binary floating point, the closest double to decimal 2.2 has exact value 2.20000000000000017763568394002504646778106689453125, and the result of converting it to float is 2.2000000476837158203125. Converting the float back to double does not change its value. 2.20000000000000017763568394002504646778106689453125 is not equal to 2.2000000476837158203125.

2.5 is exactly representable in both float and double in binary floating point systems, so neither the conversion to float nor the conversion back to double changes the value. 2.5 is equal to 2.5.

Patricia Shanahan
  • 25,849
  • 4
  • 38
  • 75
2

Floating-point numbers are likely to contain round-off error
Ref: http://www.cs.yale.edu/homes/aspnes/pinewiki/C(2f)FloatingPoint.html

Going through the documentation,
I see the following. (Point 6 in the URL above)

In general, floating-point numbers are not exact: they are likely to contain round-off error because of the truncation of the mantissa to a fixed number of bits.

The easiest way to avoid accumulating error is to use high-precision floating-point numbers (this means using double instead of float). On modern CPUs there is little or no time penalty for doing so....

One consequence of round-off error is that it is very difficult to test floating-point numbers for equality, unless you are sure you have an exact value as described above. It is generally not the case, for example, that (0.1+0.1+0.1) == 0.3 in C. This can produce odd results if you try writing something like for(f = 0.0; f <= 0.3; f += 0.1): it will be hard to predict in advance whether the loop body will be executed with f = 0.3 or not. (Even more hilarity ensues if you write for(f = 0.0; f != 0.3; f += 0.1), which after not quite hitting 0.3 exactly keeps looping for much longer than I am willing to wait to see it stop, but which I suspect will eventually converge to some constant value of f large enough that adding 0.1 to it has no effect.)

Community
  • 1
  • 1
Irf
  • 4,285
  • 3
  • 36
  • 49
  • It is usual to use the name “representation error” for the thing that bit the OP, and to reserve “round-off error” for the results of computations. In particular, the long paragraph you quote goes on about “accumulating error”, which does not make sense here, as there is not a single computation. It is a perfectly valid expectation that `==` will behave predictably in the absence of any computations (for a compiler that does the minimum of efforts to adhere to the C99 standard). – Pascal Cuoq Feb 03 '17 at 10:26