Why does double in C print fewer decimal digits than C++?

c++ c floating-point numbers precision

I have this code in C where I've declared 0.1 as double.

#include <stdio.h> 
int main() {
    double a = 0.1;

    printf("a is %0.56f\n", a);
    return 0;
}

This is what it prints, a is 0.10000000000000001000000000000000000000000000000000000000

Same code in C++,

#include <iostream>
using namespace std;
int main() {
    double a = 0.1;

    printf("a is %0.56f\n", a);
    return 0;
}

This is what it prints, a is 0.1000000000000000055511151231257827021181583404541015625

What is the difference? When I read both are alloted 8 bytes? How does C++ print more numbers in the decimal places?

Also, how can it go until 55 decimal places? IEEE 754 floating point has only 52 bits for fractional number with which we can get 15 decimal digits of precision. It is stored in binary. How come its decimal interpretation stores more?

Your C++ example seems to be missing include for the printf.

I think the question is rather why gcc and g++ give different results? They shouldn't.

To use printf you need to include <stdio.h>.

@user694733 This is a MCVE. Compile with for example gcc -std=c11 -pedantic-errors and g++ -std=c++11 -pedantic-errors. I'm able to reproduce the behavior on Mingw.

15 decimal digits of precision does not mean that the numbers you can represent have at most 15 decimal digits. For instance, the value of bit 50 is exactly 4.44089209850062616169452667236328125E-16.

Cheers and hth. - Alf

With MinGW g++ (and gcc) 7.3.0 your results are reproduced exactly.

This is a pretty weird case of Undefined Behavior.

The Undefined Behavior is due to using printf without including an appropriate header, ¹violating the “shall” in

C++17 §20.5.2.2

” A translation unit shall include a header only outside of any declaration or definition, and shall include the header lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnostic is required.

In the C++ code change <iostream> to <stdio.h>, to get valid C++ code, and you get the same result as with the C program.

Why does the C++ code even compile?

Well, unlike C, in C++ a standard library header is allowed to drag in any other header. And evidently with g++ the <iostream> header drags in some declaration of printf. Just not an entirely correct one.

Details: With MinGW g++ 7.3.0 the declaration/definition of printf depends on the macro symbol __USE_MINGW_ANSI_STDIO. The default is just that <stdio.h> declares printf. But when __USE_MINGW_ANSI_STDIO is defined as logical true, <stdio.h> provides an overriding definition of printf, that calls __mingw_vprintf. And as it happens the <cstdio> header defines (via an indirect include) __USE_MINGW_ANSI_STDIO before including <stdio.h>.

There is a comment in <_mingw.h>, "Note that we enable it also for _GNU_SOURCE in C++, but not for C case.".

In C++, with relevant versions of this compiler, there is effectively a difference between including <stdio.h> and using printf, or including <cstdio>, saying using std::printf;, and using printf.

Regarding

” Also, how can it go until 55 decimal places? IEEE 754 floating point has only 52 bits for fractional number with which we can get 15 decimal digits of precision. It is stored in binary. How come its decimal interpretation stores more?

... it's just the decimal presentation that's longer. The digits beyond the precision of the internal representation, about 15 digits for 64-bit IEEE 754, are essentially garbage, but they can be used to reconstitute the original bits exactly. At some point they will become all zeroes, and that point is reached for the last digit in your C++ program output.

^{¹Thanks to Dietrich Epp for finding that standards quote.}

Comments are not for extended discussion; this conversation has been moved to chat.

When a floating number is smaller than one, the 15-digits precision may not the case, see mathworks.com/help/matlab/ref/realmin.html

MSalters

It looks to me like both cases print 56 decimal digits, so the question is technically based on a flawed premise.

I also see that both numbers are equal to 0.1 within 52 bits of precision, so both are correct.

That leads to your final quesion, "How come its decimal interpretation stores more?". It doesn't store more decimals. double doesn't store any decimals. It stores bits. The decimals are generated.

Only one of those numbers is equal to the IEEE754 representation of 0.1, though (that is, the closest machine number to 0.1).

I agree with 1. and 3. points, however regarding point 2, I vaguely remember that this came up before, and that printf is required by the C standard to print all requested digits exactly, except for implementation-defined rounding of the last output digit. (The second output is correct for an IEEE 754 double as pointed out by Federico Poloni.) See e.g. this previous question, specifically the answers of Yu Hao and dasblinkenlight.

s/52/53/: IEEE754 binary64 has 53 digits of precision, unless the number is a denormal. It's just that 52 of them are explicitly stored.

@Ruslan -- to be absolutely clear, IEEE 754 64-bit values have 53 bits (base 2) of precision. That's about 15 digits (base 10).

Why does double in C print fewer decimal digits than C++?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Links

Contact US