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

由于这篇文章对当前的浮点实现进行了一般性的讨论，我想补充一下，有一些项目正在解决它们的问题。

看看https://posithub.org/例如，它展示了一种称为posit（及其前身unum）的数字类型，它承诺以更少的比特提供更好的精度。如果我的理解是正确的，它也解决了问题中的问题。非常有趣的项目，背后的人是数学家约翰·古斯塔夫森博士。整个过程都是开源的，用C/C++、Python、Julia和C#实现了许多实际的实现(https://hastlayer.com/arithmetics).

想象一下，以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/3不精确地存在于基数10中（它将是3.33……重复出现）一样，1/10也不存在于二进制中。

那又怎么样？如何处理？有什么解决办法吗？

为了提供最佳解决方案，我可以说我发现了以下方法：

parseFloat((0.1 + 0.2).toFixed(10)) => Will return 0.3

让我解释一下为什么这是最好的解决方案。正如上面提到的其他答案一样，使用现成的Javascript toFixed（）函数来解决问题是一个好主意。但很可能你会遇到一些问题。

假设你将两个浮点数相加，如0.2和0.7，这里是：0.2+0.7=0.8999999999999999。

您的预期结果是0.9，这意味着您需要一个精度为1位数的结果。因此，您应该使用（0.2+0.7）.tfixed（1）但是不能只给toFixed（）一个特定的参数，因为它取决于给定的数字，例如

0.22 + 0.7 = 0.9199999999999999

在本例中，您需要2位精度，因此它应该为Fixed（2），那么，适合每个给定浮点数的参数应该是什么？

你可以说在每种情况下都是10：

(0.2 + 0.7).toFixed(10) => Result will be "0.9000000000"

该死你打算怎么处理那些9后不需要的零？现在是将其转换为浮动的时候了，以实现您的愿望：

parseFloat((0.2 + 0.7).toFixed(10)) => Result will be 0.9

既然找到了解决方案，那么最好将其作为如下函数提供：

function floatify(number){
           return parseFloat((number).toFixed(10));
        }
    

让我们自己试试吧：函数floatify（数字）{return parseFloat（（number）.toFixed（10））；}函数addUp（）{var number1=+$（“#number1”）.val（）；var number2=+$（“#number2”）.val（）；var expectedResult=number1+number2；var expectedResult=浮动（number1+number2）；$（“#意外结果”）.text（意外结果）；$（“#expectedResult”）.text（expectedResult）；}addUp（）；输入{宽度：50px；}#预期结果{颜色：绿色；}#未预期结果{颜色：红色；}<script src=“https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js“></script><input id=“number1”value=“0.2”onclick=“addUp（）”onkeyup=“addUp（）”/>+<input id=“number2”value=“0.7”onclick=“addUp（）”onkeyup=“addUp（）”/>=<p>预期结果：<span id=“expectedResult”></span></p><p>意外结果：<span id=“expectedResult”></span></p>

您可以这样使用：

var x = 0.2 + 0.7;
floatify(x);  => Result: 0.9

正如W3SCHOOLS所建议的，还有另一种解决方案，您可以通过乘法和除法来解决上述问题：

var x = (0.2 * 10 + 0.1 * 10) / 10;       // x will be 0.3

请记住，（0.2+0.1）*10/10根本不起作用，尽管看起来是一样的！我更喜欢第一种解决方案，因为我可以将其作为一个函数应用，将输入浮点转换为精确的输出浮点。

仅供参考，乘法也存在同样的问题，例如0.09*10返回0.8999999999999999。应用flotify函数作为解决方法：flotify（0.09*10）返回0.9

我刚刚看到了关于浮点数的有趣问题：

考虑以下结果：

error = (2**53+1) - int(float(2**53+1))

>>> (2**53+1) - int(float(2**53+1))
1

当2**53+1时，我们可以清楚地看到一个断点——直到2**53，所有的工作都正常。

>>> (2**53) - int(float(2**53))
0

发生这种情况的原因是双精度二进制：IEEE 754双精度二进制浮点格式：binary64

从维基百科的双精度浮点格式页面：

双精度二进制浮点是PC上常用的格式，因为它的范围比单精度浮点更广，尽管它的性能和带宽成本很高。与单精度浮点格式一样，与相同大小的整数格式相比，它缺少整数的精度。它通常简称为double。IEEE 754标准规定二进制64具有：符号位：1位指数：11位有效精度：53位（显式存储52位）具有给定偏置指数和52位分数的给定64位双精度数据假设的实际值为或

感谢@aguest向我指出了这一点。