考虑以下代码:
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些不准确的情况?
最佳答案
二进制 floating point数学是这样的。在大多数编程语言中,它基于 IEEE 754 standard .问题的关键是数字以这种格式表示为整数乘以 2 的幂;分母不是二的幂的有理数(例如 0.1
,即 1/10
)无法准确表示。
对于 0.1
在标准binary64
格式,表示可以完全写成
0.1000000000000000055511151231257827021181583404541015625
十进制,或 0x1.999999999999ap-4
在 C99 hexfloat notation . 相反,有理数
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
因此不同意代码中的常量。对浮点算术问题的一个相当全面的处理是 What Every Computer Scientist Should Know About Floating-Point Arithmetic .有关更易于理解的解释,请参阅 floating-point-gui.de .
旁注:所有位置(以 N 为基数)数字系统都以精度 共享此问题
普通的旧十进制(基数为 10)数字具有相同的问题,这就是为什么像 1/3 这样的数字最终变成 0.333333333...
您刚刚偶然发现了一个数字 (3/10),它恰好很容易用十进制表示,但不适合二进制。它也是双向的(在某种程度上):1/16 在十进制 (0.0625) 中是一个丑陋的数字,但在二进制中它看起来和十进制中的 10,000 一样整齐 (0.0001)** - 如果我们在在我们的日常生活中使用基数为 2 的数字系统的习惯,你甚至会看到那个数字并本能地理解你可以通过将某些东西减半,一次又一次地减半来达到目标。
** 当然,这并不是浮点数在内存中存储的确切方式(它们使用一种科学记数法)。然而,它确实说明了二进制浮点精度错误往往会出现的一点,因为我们通常感兴趣的“现实世界”数字通常是十的幂——但仅仅是因为我们使用十进制数字系统日——今天。这也是为什么我们会说 71% 而不是“每 7 中的 5”(71% 是一个近似值,因为 5/7 不能用任何十进制数精确表示)。
所以不:二进制浮点数没有被破坏,它们只是碰巧和其他所有以 N 为基数的数字系统一样不完美:)
旁注:在编程中使用浮点数
实际上,这个精度问题意味着在显示浮点数之前,您需要使用舍入函数将浮点数舍入到您感兴趣的小数位数。
您还需要用允许一定容忍度的比较替换相等测试,这意味着:
不做
if (x == y) { ... }
而是做 if (abs(x - y) < myToleranceValue) { ... }
.哪里
abs
是绝对值。 myToleranceValue
需要为您的特定应用程序选择 - 这与您准备允许多少“摆动空间”以及您要比较的最大数字有很大关系(由于精度问题的损失) )。当心您选择的语言中的“epsilon”样式常量。这些不能用作公差值。
关于math - float 学坏了吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58838387/