0

I recently found this C code online.

#include <stdio.h>

int main() {
    double x = 3.1;
    float y = 3.1;

    if(x==y)
        printf("yes");
    else
        printf("No");
}

The output is No.

I added a few more printf calls to investigate

#include <stdio.h>

int main() {
    double x = 3.1;
    float y = 3.1;

    if(x==y)
        printf("yes");
    else
        printf("No");

    printf("%.10f\n", y);
    printf("%.10f\n", x);

    return 0;
}

The output came as

3.0999999046
3.1000000000

Why is it so? Why has the float variable lost its precision when printed to 10 decimal places?

Jøê Grèéñ
  • 551
  • 1
  • 6
  • 15
  • Because float only has ca 8 significant digits. You are printing it using 11 digits. – Klas Lindbäck Feb 19 '18 at 13:10
  • 1
    Stop finding C code online - it's obviously not helping any. – Martin James Feb 19 '18 at 13:13
  • I'd suggest you to take a look at this - http://floating-point-gui.de/formats/fp/ - because with sucha question you will get either a half-backed answer, or someonw needlessly rewriting about the same topic again. – jsbueno Feb 19 '18 at 13:14
  • 1
    @KlasLindbäck: “float only has ca 8 significant digits” is not an accurate way to explain this. Storing and printing 3.1 could be done exactly with just two significant decimal digits. The actual problem is that the OP`s implementation of `float` and `double` use a binary representation rather than a decimal representation. The stored value would not equal 3.1 no matter how many bits were used. That proves the problem is not the number of digits; it is the format of the representation. – Eric Postpischil Feb 19 '18 at 13:26
  • 1
    Short answer: because in binary, it turns out `3.1` behaves just like 1/3 = 0.33333333333333... . It's an infinitely-repeating binary fraction, so the number of significant (binary) digits -- which is obviously greater for `double` than for `float` -- makes a difference. It's sort of like asking why 0.333333333 is not equal to 0.3333333333 . – Steve Summit Feb 19 '18 at 13:29
  • @EricPostpischil Thank you for summing up the answers available in the dupes I chose when closing this question. – Klas Lindbäck Feb 19 '18 at 13:30
  • @KlasLindbäck: I did not summarize the answers in the purported originals. I corrected a misstatement. Thinking about floating-point as distorted decimal leads to misunderstanding, when the floating-point uses a binary base. It is not good to mislead people in this way. – Eric Postpischil Feb 19 '18 at 14:26
  • @EricPostpischil I am aware that my comment isn't the whole truth. I did provide accurate descriptions by providing 2 relevant dupes when I closed the question. And even if you aren't aware of it, your comment is reiterating those answers simply because they both describe the same thing, namely why many decimal numbers cannot be exactly represented in binary using IEEE. – Klas Lindbäck Feb 19 '18 at 14:45
  • 1
    @KlasLindbäck: The problem is not that the comment is not the whole truth. The problem is that it is wrong. There are floating-point formats that do store an approximate number of decimal figures, such as a format with a binary significand and a decimal exponent. Such a format could exactly store eight decimal digits and sometimes nine, so it would be correct to describe it as having approximately eight digits. Binary floating-point does not do that. It does not have decimal digits, and it is false to state that it does. The problem with this is that is misleads learners.… – Eric Postpischil Feb 19 '18 at 15:22
  • 1
    … It is possible to make correct statements about binary floating-point without misleading learners, and you do not need to write “the whole truth” to do so. You can abbreviate the issues without being misleading. One way of phrasing it might be that numbers are approximated when converted to binary floating-point, and the conversion errors are visible around the seventh decimal digit. There are other ways to phrase it. (Note also that eight is inaccurate. IEEE 754 basic 32-binary can only guarantee a round-trip for six decimal digits.) – Eric Postpischil Feb 19 '18 at 15:26
  • @EricPostpischil Your logic is flawed. I see no reason to continue this discussion. – Klas Lindbäck Feb 20 '18 at 08:02
  • @KlasLindbäck: Please state the flaw so that I can fix it. – Eric Postpischil Feb 20 '18 at 12:29

0 Answers0