鉴于没有人提到这一点。。。

一些高级语言（如Python和Java）提供了克服二进制浮点限制的工具。例如：

Python的十进制模块和Java的BigDecimal类，它们在内部使用十进制表示法（与二进制表示法相反）表示数字。两者都有有限的精度，因此它们仍然容易出错，但它们解决了二进制浮点运算中最常见的问题。小数在处理金钱时很好：10美分加20美分总是正好是30美分：>>> 0.1 + 0.2 == 0.3错误>>>十进制（'0.1'）+十进制（'0.2'）==十进制（'0.3'）真的Python的十进制模块基于IEEE标准854-1987。Python的分数模块和Apache Common的BigFraction类。两者都将有理数表示为（分子、分母）对，它们可能给出比十进制浮点运算更精确的结果。

这两种解决方案都不是完美的（特别是如果我们考虑性能，或者如果我们需要非常高的精度），但它们仍然解决了二进制浮点运算的大量问题。

想象一下，以10为基数，例如8位数的精度工作。您检查是否

1/3 + 2 / 3 == 1

并了解到这返回错误。为什么？好吧，作为真实的数字

1/3=0.333….和2/3=0.666。。。。

在小数点后八位截断，我们得到

0.33333333 + 0.66666666 = 0.99999999

当然，这与1.00000000正好相差0.00000001。

具有固定位数的二进制数的情况完全类似。作为实数，我们有

1/10=0.0001100110011001100…（底座2）

and

1/5=0.00111001100110011001…（底座2）

如果我们把这些截成七位

0.0001100 + 0.0011001 = 0.0100101

而另一方面，

3/10=0.010011001100110011…（基数2）

被截断为七位的值为0.0100110，两者相差0.0000001。

确切的情况稍显微妙，因为这些数字通常以科学符号存储。因此，例如，我们可以将其存储为1.10011*2^-4，而不是将1/10存储为0.0001100，这取决于我们为指数和尾数分配了多少位。这会影响计算的精度位数。

结果是，由于这些舍入错误，您根本不想在浮点数上使用==。相反，您可以检查它们的差值的绝对值是否小于某个固定的小数字。

二进制浮点数学是这样的。在大多数编程语言中，它基于IEEE 754标准。问题的关键在于，数字以这种格式表示为整数乘以2的幂；分母不是2的幂的有理数（如0.1，即1/10）无法精确表示。

对于标准binary64格式的0.1，表示形式可以完全写为

0.1000000000000000055511151231257827021181583404541015625（十进制），或0x1.999999999999ap-4，采用C99六进制浮点数表示法。

相比之下，有理数0.1（1/10）可以完全写成

0.1（十进制），或0x1.999999999999999…p-4，类似于C99十六进制浮点数，其中。。。表示9的无限序列。

程序中的常数0.2和0.3也将近似于其真实值。恰好最接近0.2的两倍大于有理数0.2，但最接近0.3的两倍小于有理数0.3。0.1和0.2的和最终大于有理数0.3，因此与代码中的常数不一致。

浮点运算问题的一个相当全面的处理是每个计算机科学家都应该知道的浮点运算。有关更容易理解的解释，请参阅floatingpoint-gui.de。

边注：所有位置（以N为基数）数字系统都有精度问题

普通的十进制（以10为基数）数字也有同样的问题，这就是为什么像1/3这样的数字最终会变成0.33333333。。。

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

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

所以不：二进制浮点数并没有被破坏，它们只是碰巧和其他N进制一样不完美：）

边注：在编程中使用浮点

实际上，这种精度问题意味着在显示浮点数之前，需要使用舍入函数将浮点数舍入到您感兴趣的小数位数。

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

如果（x==y）｛…｝则不执行

相反，如果（abs（x-y）<myToleranceValue）｛…｝，则执行此操作。

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

除了其他正确答案之外，您可能还需要考虑缩放值以避免浮点运算的问题。

例如：

var result = 1.0 + 2.0;     // result === 3.0 returns true

…而不是：

var result = 0.1 + 0.2;     // result === 0.3 returns false

在JavaScript中，表达式0.1+0.2===0.3返回false，但幸运的是，浮点中的整数运算是精确的，因此可以通过缩放来避免十进制表示错误。

作为一个实际的例子，为了避免精度至关重要的浮点问题，建议1将钱作为一个整数来处理：2550美分而不是25.50美元。

1 Douglas Crockford：JavaScript：好的部分：附录A——糟糕的部分（第105页）。

从Python 3.5开始，您可以使用math.isclose（）函数来测试近似相等性：

>>> import math
>>> math.isclose(0.1 + 0.2, 0.3)
True
>>> 0.1 + 0.2 == 0.3
False

一些统计数据与这个著名的双精度问题有关。

当使用0.1（从0.1到100）的步长将所有值（a+b）相加时，精度误差的概率约为15%。请注意，该错误可能会导致稍大或稍小的值。以下是一些示例：

0.1 + 0.2 = 0.30000000000000004 (BIGGER)
0.1 + 0.7 = 0.7999999999999999 (SMALLER)
...
1.7 + 1.9 = 3.5999999999999996 (SMALLER)
1.7 + 2.2 = 3.9000000000000004 (BIGGER)
...
3.2 + 3.6 = 6.800000000000001 (BIGGER)
3.2 + 4.4 = 7.6000000000000005 (BIGGER)

当使用0.1（从100到0.1）的步长减去所有值（a-b，其中a>b）时，我们有大约34%的精度误差。以下是一些示例：

0.6 - 0.2 = 0.39999999999999997 (SMALLER)
0.5 - 0.4 = 0.09999999999999998 (SMALLER)
...
2.1 - 0.2 = 1.9000000000000001 (BIGGER)
2.0 - 1.9 = 0.10000000000000009 (BIGGER)
...
100 - 99.9 = 0.09999999999999432 (SMALLER)
100 - 99.8 = 0.20000000000000284 (BIGGER)

*15%和34%确实是巨大的，所以当精度非常重要时，请始终使用BigDecimal。使用2个十进制数字（步骤0.01），情况会进一步恶化（18%和36%）。