浮点数被破坏了吗？

豪毅

考虑以下代码：
# l' ^: X  J  K+ h0.1   0.2 == 0.3  ->  false0.1   0.2                ->  0.30000000000000004为什么会出现这些错误？
                                                               
4 ]7 Q! Z9 ^# ^3 `' M- N# X    解决方案:                                                               
                                                                二进制浮点数学就是这样。它基于大多数编程语言IEEE 754 标准。问题的关键在于，数字以这种格式表示为整数乘以 2 的幂。不能准确表示分母不是 2 次方的有理数(如0.1，即）。1/10
+ N+ r. }: t1 R因为0.1在标准binary在64格式中，表示可以完全写成
4 k3 B9 Z0 Y& l7 Q0.1000000000055151257270218340454015625 十进制
) E. _# [) D4 O: F' u0x1.999999999999ap-4在C99 hexfloat 在表示法中。相反，有理数0.1，即1/10，可以完全写成
0.或
0x1.99999999999999...p-4在 C99 hexfloat 表示法的类似物，其中...表示 9 无休止序列。常数0在程序中.2和0.3也类似于它们的真实值。碰巧最接近double的0.2大于有理数0.2，但最接近double的0.3小于有理数0.3。0.1和的总和0.最终大于理数0.因此，它与代码中的常数不一致。
  K% l# `1 x4 B# g浮点算术问题的综合处理是每个计算机科学家都应该知道浮点算术的知识。请参考更容易理解的解释floating-point-gui.de。
2 k3 z0 x8 c9 @5 L& q9 i旁注：所有位置（base-N）数字系统都精确地共享这个问题
老十进制(以 10 为底)的普通数字也有同样的问题，这就是为什么 1/3 这样的数字最终会变成 0.333333333…
你只是偶然发现了一个数字 (3/10)，很容易用十进制系统表示，但不适合二进制系统。它也是双向的(在某种程度上):1/16 是十进制的丑数(0.0625)，但在二进制中，它看起来像十进制的万分之一(0.0001）** - 如果我们在日常生活中使用 2 的数字系统，你甚至会看到这个数字，本能地理解你可以通过减半一次又一次地到达那里。
1 A- [2 G/ Y: a* j** 当然，内存中浮点的存储方法并不完全正确（它们使用科学的记数法）。然而，它确实表明，这经常发生在二进制浮点的精度错误中，因为我们通常对现实世界感兴趣的数字通常是10米 -只是因为我们使用了十进制数字系统 -今天。这就是为什么我们会说 71% ，而不是每 7 中有 5 (71% 是近似值，因为 5/7 不能用任何十进制数准确表示)。
所以不:二进制浮点数没有被破坏，只是碰巧和其他一切都是基于 N 数字系统同样不完美
旁注：编程中使用浮点数
' t# _) |+ ~' ~6 N' j- }6 \在实践中，这个精度问题意味着你需要用舍入函数四舍五入你感兴趣的小数字，然后显示它们。
; M/ ~5 k# c8 g) a6 O9 ]0 O您还需要使用允许一定容差的比较来替换相等测试，这意味着：
+ V; V3 W2 A5 L7 g/ T4 c不要做_if (x == y) { ... }
而是做if (abs(x - y)
其中abs是绝对值。myToleranceValue您需要为您的特定应用程序选择 - 这与你准备的摆动空间和你想要比较的最大数字（精度损失）有很大关系）。请注意您选择的语言中的epsilon样式常量不能作为公差值。