想象一下，以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，这取决于我们为指数和尾数分配了多少位。这会影响计算的精度位数。

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

你试过胶带解决方案了吗？

尝试确定错误发生的时间，并用简短的if语句修复它们，这并不漂亮，但对于某些问题，这是唯一的解决方案，这就是其中之一。

 if( (n * 0.1) < 100.0 ) { return n * 0.1 - 0.000000000000001 ;}
                    else { return n * 0.1 + 0.000000000000001 ;}    

我在c#的一个科学模拟项目中也遇到过同样的问题，我可以告诉你，如果你忽视蝴蝶效应，它会变成一条大胖龙，咬你一口**

不，不破，但大多数小数必须近似

总结

浮点运算是精确的，不幸的是，它与我们通常的以10为基数的数字表示法不太匹配，所以我们经常给它的输入与我们写的略有不同。

即使是像0.01、0.02、0.03、0.04…0.24这样的简单数字也不能精确地表示为二进制分数。如果你数到0.01、.02、.03…，直到你数到0.25，你才能得到以2为底的第一个分数。如果你尝试使用FP，那么你的0.01会稍微有点偏差，所以要将其中的25个相加到一个精确的0.25，就需要一长串的因果关系，包括保护位和舍入。很难预测，所以我们举手说“FP不准确”，但事实并非如此。

我们不断地给FP硬件一些在基数10中看似简单但在基数2中却是重复的分数。

这是怎么发生的？

当我们用十进制书写时，每个分数（特别是每个终止的小数）都是形式的有理数

          a/（2n x 5m）

在二进制中，我们只得到2n项，即：

a/2n

所以在十进制中，我们不能表示1/3。因为基数10包括2作为素因子，所以我们可以写成二进制分数的每个数字也可以写成基数10的分数。然而，我们写为10进制分数的任何东西都很难用二进制表示。在0.01、0.02、0.03…0.99的范围内，只有三个数字可以用我们的FP格式表示：0.25、0.50和0.75，因为它们是1/4、1/2和3/4，所有的数字都只使用2n项。

在base10中，我们不能表示1/3。但在二进制中，我们不能做1/10或1/3。

因此，虽然每一个二进制分数都可以用十进制来表示，但反过来却不正确。事实上，大多数小数在二进制中重复。

处理它

开发人员通常被要求进行＜epsilon比较，更好的建议可能是舍入为整数值（在C库中：round（）和round f（），即保持FP格式），然后进行比较。舍入到特定的小数部分长度可以解决大多数输出问题。

此外，在实数运算问题（FP是在早期昂贵的计算机上为之发明的问题）上，宇宙的物理常数和所有其他测量值只为相对较少的有效数字所知，因此整个问题空间无论如何都是“不精确的”。FP“精度”在这种应用中不是问题。

当人们尝试使用FP进行计数时，整个问题就真的出现了。它确实可以做到这一点，但前提是你坚持使用整数值，这会破坏使用它的意义。这就是为什么我们拥有所有这些小数软件库的原因。

我喜欢克里斯的披萨回答，因为它描述了实际问题，而不仅仅是关于“不准确”的通常手写。如果FP只是“不准确”，我们可以修复它，而且几十年前就已经做到了。我们没有这样做的原因是因为FP格式紧凑快速，是处理大量数字的最佳方式。此外，这也是太空时代和军备竞赛以及早期使用小型内存系统解决速度非常慢的计算机的大问题的尝试所留下的遗产。（有时，单个磁芯用于1位存储，但这是另一回事。）

结论

如果您只是在银行数豆子，那么首先使用十进制字符串表示的软件解决方案工作得非常好。但你不能这样做量子色动力学或空气动力学。

另一种方法是：使用64位来表示数字。因此，无法精确表示超过2**64=18446744073709551616个不同的数字。

然而，Math表示，在0和1之间已经有无限多的小数。IEE 754定义了一种编码，以有效地将这64位用于更大的数字空间加上NaN和+/-无穷大，因此在精确表示的数字之间存在间隙，只填充近似的数字。

不幸的是，0.3存在差距。

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

一些高级语言（如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的情况下工作，则0.1将是1 x 10⁻¹，0.2将是2 x 10⁻¹，0.3将是3 x 10⁻¹. 整数运算简单而准确，所以加上0.1+0.2显然会得到0.3。

计算机通常不以10为基数工作，而是以2为基数工作。对于某些值，仍然可以得到精确的结果，例如0.5是1 x 2⁻¹和0.25是1 x 2⁻²，将它们相加，结果为3 x 2⁻²或0.75。确切地

问题是数字可以精确地以10为基数表示，但不能以2为基数。这些数字需要四舍五入到最接近的相等值。假设非常常见的IEEE 64位浮点格式，最接近0.1的数字是3602879701896397 x 2⁻⁵⁵, 最接近0.2的数字是7205759403792794 x 2⁻⁵⁵; 将它们相加，得到10808639105689191 x 2⁻⁵⁵, 或精确的十进制值0.30000000000000000444089209850062616169452667236328125。浮点数通常四舍五入以显示。