考虑以下代码：
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些错误？
当前回答
一些统计数据与这个著名的双精度问题有关。
当使用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%）。
其他回答
这个问题的许多重复问题都是关于浮点舍入对特定数字的影响。在实践中，通过查看感兴趣的计算的确切结果而不是仅仅阅读它，更容易了解它的工作原理。一些语言提供了实现这一点的方法，例如在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，以偶数结尾，因此是正确的结果。
你试过胶带解决方案了吗？
尝试确定错误发生的时间，并用简短的if语句修复它们，这并不漂亮，但对于某些问题，这是唯一的解决方案，这就是其中之一。
if( (n * 0.1) < 100.0 ) { return n * 0.1 - 0.000000000000001 ;}
else { return n * 0.1 + 0.000000000000001 ;}
我在c#的一个科学模拟项目中也遇到过同样的问题，我可以告诉你，如果你忽视蝴蝶效应，它会变成一条大胖龙，咬你一口**
鉴于没有人提到这一点。。。
一些高级语言（如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.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位存储，但这是另一回事。）
结论
如果您只是在银行数豆子，那么首先使用十进制字符串表示的软件解决方案工作得非常好。但你不能这样做量子色动力学或空气动力学。
二进制浮点数学是这样的。在大多数编程语言中，它基于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阈值。
