math - float 学坏了吗？

Question

考虑以下代码:

0.1 + 0.2 == 0.3  ->  false

0.1 + 0.2         ->  0.30000000000000004

为什么会出现这些错误？

Answer 1

二进制 floating point数学就是这样。在大多数编程语言中，它基于 IEEE 754 standard .问题的症结在于，数字以这种格式表示为整数乘以 2 的幂；分母不是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 .

Side Note: All positional (base-N) number systems share this problem with precision

普通的旧十进制(基数为 10)数字也有同样的问题，这就是为什么像 1/3 这样的数字最终会变成 0.333333333...

您刚刚偶然发现了一个数字 (3/10)，它恰好很容易用十进制表示，但不适合二进制系统。它也是双向的(在某种程度上):1/16 是一个丑陋的十进制数字 (0.0625)，但在二进制中它看起来和十进制中的第 10,000 一样整洁 (0.0001)** - 如果我们在在我们的日常生活中习惯使用以 2 为底的数字系统，你甚至会看到这个数字并本能地理解你可以通过将某物减半、再减半、一次又一次地到达那里。

当然， float 在内存中的存储方式并非如此(它们使用一种科学记数法)。然而，它确实说明了二进制浮点精度错误往往会出现这一点，因为我们通常感兴趣的“现实世界”数字通常是十的幂——但这只是因为我们使用十进制数字系统日——今天。这也是为什么我们会说 71% 而不是“每 7 个中有 5 个”(71% 是一个近似值，因为 5/7 不能用任何小数精确表示)。

所以不:二进制 float 并没有被破坏，它们只是碰巧和其他所有以 N 为基数的数字系统一样不完美:)

Side Side Note: Working with Floats in Programming

在实践中，这个精度问题意味着您需要使用舍入函数将 float 舍入到您感兴趣的小数位数，然后再显示它们。

您还需要用允许一定容差的比较替换相等性测试，这意味着:

不做if (x == y) { ... }

改为执行 if (abs(x - y) < myToleranceValue) { ... } .

哪里abs是绝对值。 myToleranceValue需要为您的特定应用程序选择 - 这与您准备允许的“摆动空间”有很大关系，以及您要比较的最大数字可能是多少(由于精度问题的损失) ).当心您选择的语言中的“epsilon”样式常量。这些可以用作公差值，但它们的有效性取决于您使用的数字的大小(大小)，因为大数字的计算可能会超过 epsilon 阈值。