c - 为什么以及如何，这个 C 程序是否准确显示 7.21？

Question

我很熟悉这样一个事实，即小数通常不能整齐地转换为二进制，因此存储了一个近似值，当转换回十进制时与原始数字有点偏差。我相信 0.21 就是这样一个分数的例子。

这个程序如何以及为什么在 gcc 中编译并准确显示 7.21？

并且(此问题的重要第二部分)，为什么它准确显示 7.21，却不准确显示 839.21？

我能理解为什么它会不准确地显示 0.21，或者不准确地显示任何数字点 21，因为它需要很多位才能将其准确地放入二进制中，即使是一个。但我希望它始终不准确地显示 n.21 而不管整数 n 是什么

printf("%.100f\n", 7.21);  
printf("%.100f\n", 839.21); 
produces 7.210000000000000000000... 
839.2100000000000400000....

知道为什么它一个准确而另一个不准确吗？ (无论如何在我的 gcc 编译器上!)

如果相关，gcc --version 显示 gcc.exe (rubenvb-4.5.4) 4.5.4 版权所有 (C) 2010 Free Software Foundation, Inc.

我和一个人谈过，他说他得到的两者都不准确，这更符合人们的预期。所以我拍了一个展示行为的屏幕显示

注意- 我注意到我的 cygwin gcc 实现不是最新的 cygwin gcc 实现.. 我只是在 where gcc 上运行它从 C:\Perl64\site\bin\gcc.exe 所以它没有运行 cygwin。它可能正在运行一个旧的 ming(这是 R 的建议)。 chux 是 cygwin n GNU C11 (GCC) 版本 6.4.0 (i686-pc-cygwin)`。

Answer 1

How and why is this program compiled in gcc showing 7.21 accurately?

旧版 printf() 对最低有效十进制数字的处理是有限的。

printf("%.100f\n", x); 不需要打印x 准确传递了某个数字。确实没有关于此的 C 规范，但对于 DBL_DIG 数字(通常为 15)，十进制输出应该至少正确 - 这将是“弱”和有问题的。

更好且通常可接受的 printf() 至少对 DBL_DECIMAL_DIG 位(通常为 17)是正确的。如果不追求无限的精度，让最后一位数字正确可能会很麻烦。见 Table-maker's dilemma 。用零而不是正确的数字填充“正确”的情况并不少见。 这就是 OP 的代码所做的。它转到正确的四舍五入的 17 位数字，然后用零填充。

高质量的 printf() 会为所有数字正确打印 double x = 839.21; 和 x = 7.21;。例如:

839.2100000000000363797880709171295166015625...
839.210000000000000019984014443252817727625370025634765625.... (as long double)
vs OP's
839.2100000000000400000....

123.4567890123456789 // digit place

7.20999999999999996447286321199499070644378662109375...
7.210000000000000000034694469519536141888238489627838134765625000... (as long double)
7.210000000000000000000

OP 的 printf() 最多只能使用 16 位左右的数字。

7.210000000000000000000.... 的输出看起来不错，因为 printf() 输出到一个点，然后用零填充。参见 @Eric Postpischil 和 luck

---

注意:某些优化将使用 long double(研究 FLT_EVAL_METHOD)执行任务，因此 long double 也作为 x86 extended precision 结果发布。

由 Barlop 添加

Eric Postpischil 的一些额外观点

OP's printf is not exact for 7.21. OP's printf was passed exactly 7.20999999999999996447286321199499070644378662109375, but it printed 7.210…, so it is wrong. It just happens to be wrong in a way that the error in that the OP's printf exactly cancelled out the error that occurred when 7.21 was rounded to binary floating-point.

Eric 是正确的，printf("%.100f\n", 7.20999999999999996447286321199499070644378662109375);打印 7.210000000

Eric 详细说明了他是如何知道发送到 printf 的是 7.20999999999999996447286321199499070644378662109375，而不是其他一些接近它的长数字。

Eric 评论说他知道，通过使用良好的 C 实现，将源代码中的十进制数字正确转换为二进制 float 并正确打印。 (苹果在 macOS 上的开发者工具。)并使用了他编写的一些 Maple(数学软件)代码来帮助他进行浮点运算。在没有这些的情况下，他可能不得不像在小学时那样计算很长的路，但要用更多的数字。