问题描述
二进制浮点数学是这样的。在大多数编程语言中，它基于IEEE 754 标准。问题的症结在于，数字以这种格式表示为整数乘以 2 的幂。不能精确表示分母不是 2 次方的有理数（例如0.1，即）。1/10
因为0.1在标准binary64格式中，表示可以完全写成
-
0.1000000000000000055511151231257827021181583404541015625十进制，或 -
0x1.999999999999ap-4在C99 hexfloat 表示法中。
相反，有理数0.1，即1/10，可以完全写为
-
0.1十进制，或 -
0x1.99999999999999...p-4在 C99 hexfloat 表示法的类似物中，其中...表示 9 的无休止序列。
程序中的常数0.2和0.3也将近似于它们的真实值。碰巧最接近double的0.2大于有理数0.2，但最接近double的0.3小于有理数0.3。0.1和的总和0.2最终大于有理数0.3，因此与代码中的常数不一致。
浮点算术问题的一个相当全面的处理是每个计算机科学家都应该知道的关于浮点算术的知识。有关更易于理解的解释，请参阅floating-point-gui.de。
普通的旧十进制（以 10 为底）数字也有同样的问题，这就是为什么像 1/3 这样的数字最终会变成 0.333333333…
您刚刚偶然发现了一个数字 (3/10)，它恰好很容易用十进制系统表示，但不适合二进制系统。它也是双向的（在某种程度上）：1/16 是十进制的丑数（0.0625），但在二进制中它看起来就像十进制中的万分之一一样整洁（0.0001）** - 如果我们在在我们的日常生活中使用以 2 为底的数字系统的习惯，你甚至会看到这个数字并本能地理解你可以通过减半来达到那里，一次又一次地减半。
** 当然，浮点数在内存中的存储方式并不完全正确（它们使用一种科学记数法）。然而，它确实说明了二进制浮点精度错误往往会出现这一点，因为我们通常感兴趣的“现实世界”数字通常是十的幂 - 但仅仅是因为我们使用十进制数字系统 -今天。这也是为什么我们会说 71% 而不是“每 7 个中有 5 个”之类的东西（71% 是一个近似值，因为 5/7 不能用任何十进制数精确表示）。
所以不：二进制浮点数没有被破坏，它们只是碰巧和其他所有基于 N 的数字系统一样不完美:)
在实践中，这个精度问题意味着您需要使用舍入函数将浮点数四舍五入到您感兴趣的小数位，然后再显示它们。
您还需要用允许一定容差的比较替换相等测试，这意味着：
不要做_if (x == y) { ... }
而是做if (abs(x - y) < myToleranceValue) { ... }.
其中abs是绝对值。myToleranceValue需要为您的特定应用程序选择 - 这与您准备允许多少“摆动空间”以及您要比较的最大数字可能是多少（由于精度问题的损失）有很大关系）。请注意您选择的语言中的“epsilon”样式常量。这些不能用作公差值。
解决方法
考虑以下代码：
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些错误？