考虑以下代码：
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些错误？
当前回答
鉴于没有人提到这一点。。。
一些高级语言（如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类。两者都将有理数表示为（分子、分母）对，它们可能给出比十进制浮点运算更精确的结果。
这两种解决方案都不是完美的（特别是如果我们考虑性能，或者如果我们需要非常高的精度），但它们仍然解决了二进制浮点运算的大量问题。
其他回答
一些统计数据与这个著名的双精度问题有关。
当使用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%）。
可以在数字计算机中实现的浮点数学必须使用实数的近似值及其运算。（标准版文件长达50多页，并有一个委员会处理其勘误表和进一步完善。）
这种近似是不同类型的近似的混合，每一种都可以被忽略或仔细考虑，因为其偏离精确性的特定方式。它还涉及到许多硬件和软件层面的明确例外情况，大多数人都会走过来假装没有注意到。
如果您需要无限精度（例如，使用数字π，而不是其许多较短的替代项之一），您应该编写或使用符号数学程序。
但是，如果您同意浮点数学有时在值和逻辑上是模糊的，错误可能会很快累积，并且您可以编写需求和测试来考虑这一点，那么您的代码可以经常通过FPU中的内容。
它被打破的方式与你在小学学习并每天使用的十进制（以10为基础）表示法完全相同，只是以2为基础。
要理解，请考虑将1/3表示为十进制值。这是不可能做到的！世界将在你写完小数点后的3之前结束，所以我们写了一些地方，认为它足够准确。
以同样的方式，1/10（十进制0.1）不能以2为基数（二进制）精确地表示为“十进制”值；小数点后的重复模式将永远持续下去。该值不精确，因此无法使用常规浮点方法对其进行精确计算。与基数10一样，还有其他值也显示了这个问题。
我可以补充一下吗；人们总是认为这是一个计算机问题，但如果你用手（以10为基数）计算，你就不能得到（1/3+1/3=2/3）=真，除非你有无穷大可以将0.333…加到0.333……就像（1/10+2/10）一样==基数2的3/10问题，您将其截断为0.333+0.333=0.666，并可能将其舍入为0.667，这在技术上也是不准确的。
用三进制数，三分之三不是问题——也许有人会问为什么你的十进制数学被打破了。。。
你试过胶带解决方案了吗？
尝试确定错误发生的时间，并用简短的if语句修复它们，这并不漂亮，但对于某些问题，这是唯一的解决方案，这就是其中之一。
if( (n * 0.1) < 100.0 ) { return n * 0.1 - 0.000000000000001 ;}
else { return n * 0.1 + 0.000000000000001 ;}
我在c#的一个科学模拟项目中也遇到过同样的问题，我可以告诉你，如果你忽视蝴蝶效应，它会变成一条大胖龙，咬你一口**
