想象一下，以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#的一个科学模拟项目中也遇到过同样的问题，我可以告诉你，如果你忽视蝴蝶效应，它会变成一条大胖龙，咬你一口**

已经发布了很多好的答案，但我想再补充一个。

并非所有数字都可以通过浮点数/双精度表示例如，在IEEE754浮点标准中，数字“0.2”将以单精度表示为“0.200000003”。

用于在引擎盖下存储实数的模型将浮点数表示为

即使您可以轻松键入0.2，FLT_RADIX和DBL_RADIX都是2；对于使用“IEEE二进制浮点运算标准（ISO/IEC Std 754-1985）”的带有FPU的计算机，不是10。

所以准确地表示这些数字有点困难。即使在没有任何中间计算的情况下显式指定此变量。

这个问题的许多重复问题都是关于浮点舍入对特定数字的影响。在实践中，通过查看感兴趣的计算的确切结果而不是仅仅阅读它，更容易了解它的工作原理。一些语言提供了实现这一点的方法，例如在Java中将浮点或双精度转换为BigDecimal。

由于这是一个语言不可知的问题，因此需要语言不可知工具，例如十进制到浮点转换器。

将其应用于问题中的数字，视为双精度：

0.1转换为0.1000000000000000055511151231257827021181583404541015625，

0.2转换为0.200000000000000011102230246251565404236316680908203125，

0.3转换为0.299999999999999988897769753748434595763683319091796875，以及

0.300000000000000004转换为0.30000000000000000444089209850062616169452667236328125。

手动或在十进制计算器（如Full Precision calculator）中添加前两个数字，显示实际输入的精确和为0.30000000000000000166533453693773481063544750213623046875。

如果四舍五入到等于0.3，则舍入误差将为0.000000000000000027755575615628913510591702705078125。四舍五入等于0.300000000000000004也会产生舍入误差0.000000000000000027755575615628913510591702705078125。打成平手的规则适用。

返回浮点转换器，0.300000000000000004的原始十六进制是3fd333333333334，以偶数结尾，因此是正确的结果。

二进制浮点数学是这样的。在大多数编程语言中，它基于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阈值。

浮点数的陷阱是它们看起来像十进制，但它们是二进制的。

2的唯一素因子是2，而10的素因子为2和5。这样做的结果是，每一个可以完全写成二进制分数的数字也可以完全写成十进制分数，但只有一部分可以写成十进制分数的数字可以写成二进制分数。

浮点数本质上是一个有效位数有限的二进制分数。如果你超过这些有效数字，那么结果将被四舍五入。

当您在代码中键入文字或调用函数将浮点数解析为字符串时，它需要一个十进制数，并将该十进制数的二进制近似值存储在变量中。

当您打印浮点数或调用函数将浮点数转换为字符串时，它将打印浮点数的十进制近似值。可以将二进制数字精确地转换为十进制，但在转换为字符串*时，我所知道的任何语言都不会默认这样做。一些语言使用固定数量的有效数字，其他语言使用最短的字符串，该字符串将“往返”返回到相同的浮点值。

*Python在将浮点数转换为“decimal.decimal”时确实会进行精确的转换。这是我所知道的获得浮点数的精确十进制等效值的最简单方法。