什么？0.1 + 0.2 !== 0.3？原来是因为这个

深入理解浮点数精度丢失：从二进制到IEEE754

转载于 2023-03-03 09:10:00 发布 · 850 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzA5MjQwMzQyNw==&mid=2650766212&idx=1&sn=907392660ab809d9ebf7634557fa5b6e&chksm=88667808bf11f11ea8b0bd82d98ecdca1b12470b17541f0bebad73529be92f04d6dc1c3cf92c&scene=126&sessionid=0

大家好，我是若川。我持续组织了近一年的源码共读活动，感兴趣的可以点此扫码加我微信 lxchuan12 参与。欢迎星标我的公众号~不错过推文~

浮点数精度丢失，一直是前端面试八股文里很常见的一个问题，今天我们就来深入的了解一下问题背后的原理，以及给一些日常处理的小技巧。

Musa 2023

现象：不听话的小数

我们先来看两个现象：

0.1 + 0.2 ≠ 0.3

2.55.toFixed(1) = 2.5，而 1.55.toFixed(1) = 1.6

但凡你稍微有点前端开发经验，第一个现象你就一定见过，而第二个现象却相对少见，不过其实它们底层的原理是相通的，让我们看看这里到底发生了什么。

背景：数学知识

为了更好的理解后面的计算原理，我们先来复习一些数学知识：

在数学里，小数是可以无限位的，但计算机存储介质有限，不可能全部存下，因此在计算机领域的所有小数都只是个近似值。
科学计数法是一种计数方式，把一个数表示成a与10的n次幂相乘（1≤ |a| < 10），缩写：aEn = a * 10^n。
用科学计数法可以免去浪费很多空间和时间。
一个数的负n次幂等于这个数的n次幂的倒数，10^-2 = 1 / (10^2) = 1/100。
十进制的近似值：四舍五入，二进制的近似值：零舍一入。

溯源：二进制转换

正整数的转换方法：除二取余，然后倒序排列，高位补零。

例如65的转换

（65转二进制为 1000001，高位0后为01000001）

负整数的转换方法：将对应的正整数转换成二进制后，对二进制取反，然后对结果再加一（这个操作实际上是一个便捷操作，其底层原理涉及到补码知识，感兴趣的可以看看文末的参考资料）。

例如-65
先把65转换成二进制 01000001
逐位取反：10111110
再加1：10111111（补码）

小数的转换方法：对小数点以后的数乘以2，取整数部分，再取小数部分乘2，以此类推……直到小数部分为0或位数足够。取整部分按先后顺序排列即可。

例如123.4:
0.4*2=0.8 ——————-> 取0
0.8*2=1.6 ——————-> 取1
0.6*2=1.2 ——————-> 取1
0.2*2=0.4 ——————-> 取0
0.4*2=0.8 ——————-> 取0
………… 后面就是循环了
按顺序写出：0.4 = 0.01100110……（0110循环）
整数部分123的二进制是 1111011
则123.4的二进制表示为：1111011.011001100110……

发现了什么？十进制小数转二进制后大概率出现无限位数！但计算机存储是有限的啊，怎么办呢？来，我们接着看。

溯源：浮点型存储机制

浮点型数据类型主要有：单精度（float）、双精度（double）

单精度浮点数（float）

在内存中占4个字节、有效数字8位、表示范围：-3.40E+38 ~ +3.40E+38

双精度浮点数（double）

在内存中占8个字节、有效数字16位、表示范围：-1.79E+308 ~ +1.79E+308

溯源：IEEE 754与ECMAScript

IEEE 754

所谓 IEEE754 标准，全称 IEEE 二进制浮点数算术标准，这个标准定义了表示浮点数的格式等内容，类似这样：

value = sign x exponent x franction

也就是浮点数的实际值，等于符号位（sign bit）乘以指数偏移值(exponent bias)再乘以分数值(fraction)。

在 IEEE754 中，规定了四种表示浮点数值的方式：单精确度（32位）、双精确度（64位）、延伸单精确度、延伸双精确度。

ECMAScript 对于IEEE754的实践

ECMAScript 中的 Number 类型使用 IEEE 754 标准来表示整数和浮点数值，采用的就是双精确度，也就是说，会用 64 位来储存一个浮点数。

在这个标准下，我们会用1位存储 S(sign)，0 表示正数，1 表示负数。用11位存储 E(exponent) + bias，对于11位来说，bias 的值是 2^(11-1) - 1，也就是 1023。用 52 位存储 Fraction。

举个例子，就拿 0.1 来看，对应二进制是 1 * 1.1001100110011…… * 2^-4， Sign 是 0，E + bias 是 -4 + 1023 = 1019，1019 用二进制表示是 1111111011，Fraction 是 1001100110011……

对应 64 位的完整表示就是：

0 01111111011 1001100110011001100110011001100110011001100110011010

同理, 0.2 表示的完整表示是：

0 01111111100 1001100110011001100110011001100110011001100110011010

可以看出来在转换为二进制时

0.1 >>> 0.0001 1001 1001 1001...（1001无限循环）
0.2 >>> 0.0011 0011 0011 0011...（0011无限循环）

将0.1和0.2的二进制形式按实际展开，末尾补零相加，结果如下：

0.00011001100110011001100110011001100110011001100110011010
+0.00110011001100110011001100110011001100110011001100110100
=0.01001100110011001100110011001100110011001100110011001110

用科学计数法表示为：

1.001100110011001100110011001100110011001100110011010 * 2^(-2)

省略尾数最后的0，即：

1.00110011001100110011001100110011001100110011001101 * 2^(-2)

因此 0.1 + 0.2 实际存储时的形式是：

0 01111111101 0011001100110011001100110011001100110011001100110100

再转十进制为：0.30000000000000004

好了，奇怪的东西出现了， 0.1 + 0.2 竟然不等于 0.3！

小

结

计算机存储双进度浮点数，需要先把十进制转换为二进制的科学计数法形式，然后计算机以一定的规则（IEEE 754）存储，因为存储时有位数限制（双进度8字节，64位），末位就需要取近似值（0舍1入），再转换为十进制时，就造成了误差。

破案！收工。

解法

既然知道问题所在了，那么有什么好的解决办法呢？这里给大家提供几种思路。

简单解法

纯展示类

比如你从后端拿到 2.3000000000000001 这种数据要展示时，可以先用 toPrecision 方法保留一定位数的精度，然后再 parseFloat 后显示

parseFloat(2.3000000000000001.toPrecision(12)) === 2.3 // true

网上有人给出了这里的默认精度建议为 12，这是一个经验值，一般12位足够解决掉大部分0001和0009问题，如果需要更精确可以自己调整即可。

运算类

对于需要计算的场景（四则运算），就不能粗暴的用 toPrecision了。一个更好的做法是把小数转成整数后再运算。

我们可以把需要计算的数字升级成计算机能够精确识别的整数（乘以10的n次幂），等计算完成后再进行降级（除以10的n次幂），这是大部分语言处理精度问题常用方法。

0.1 + 0.2 === 0.3 //false
(0.1 * 10 + 0.2 * 10)/10 === 0.3 //true
(0.1 * 100 + 0.2 * 100)/100 === 0.3 //true
35.41 * 100 === 3540.9999999999995 // true
// 即使扩大再缩小 还是会有丢失精度的问题
(35.41 * 100 * 100)/100 === 3541 //false  
Math.round(35.41 * 100) === 3541 //true

看起来还不能单纯的用扩大缩小法来解决丢失精度的问题。

我们可以将浮点数toString后indexOf(".")，记录一下两个值小数点后面的位数的长度，做比较，取最大值(即为扩大多少倍数)，计算完成之后再缩小回来。

// 加法运算
function add(num1, num2) {
  const num1Digits = (num1.toString().split('.')[1] || '').length
  const num2Digits = (num2.toString().split('.')[1] || '').length
  const multiplier = 10 ** Math.max(num1Digits, num2Digits)
  return (num1 * multiplier + num2 * multiplier) / multiplier
}

第三方库

在一些对数据精度要求极高的场景，可以直接使用一些现成的库，这些库本身封装了较为复杂的计算方式，相对而言更加精准，比如处理大数的 bignumber.js，处理小数的number-precision 和 decimal.js，都是不错的库。

类似问题

还记得我们最开始展示了两种现象？上面我们只还原了第一个现象（即 0.1 + 0.2问题），接下来我们简单聊下 Number.toFixed 产生的四舍五入问题。再看下这个现象：

我们用 toPrecision 多保留点精度看下：

原来如此！toFixed 方法会根据你传入的精度对数字进行四舍五入，而2.55实际上是2.54999……取1位精度的话，由于第二位是4，四舍五入之后就是2.5。而1.55如果取1位精度的话，由于第二位是5，四舍五入后就是1.6。

那此类问题又是怎么解呢？网上给了一种通用的解法，在四舍五入前，给数字加一个极小值，比如 1e-14：

这样处理后，大部分场景下的精度基本都够用了。

这里我们采用的极小值是10的负14次方（1e-14），有没有一个官方推荐的极小值常量呢？嘿，巧了，还真有！ES6在 Number 对象上新增了一个极小的常量Number.EPSILON：

Number.EPSILON
// 2.220446049250313e-16
Number.EPSILON.toFixed(20)
// "0.00000000000000022204"

引入一个这么小的量，目的在于为浮点数计算设置一个误差范围，如果误差能够小于Number.EPSILON，我们就可以认为结果是可靠的。可以抽一个误差检查函数：

// 误差检查函数
function withinErrorMargin (left, right) {
  return Math.abs(left - right) < Number.EPSILON
}


withinErrorMargin(0.1+0.2, 0.3)

看，0.3 - ( 0.1 + 0.2 ) 的误差是1e-17次方，小于 Number.EPSILON，那么我们就认为二者在大部分场景下是等值的。

解法总结

1. 数据展示类，可以直接使用toPrecision(12)凑整，再parseFloat后展示

2. 浮点数计算类，取二者中小数位数最长者（记为N），同时乘以10的N次幂，转换为整数进行计算，再除以N次幂转回小数

3. 需要用toFixed取近似值的地方，可以先加上1e-14或Number.EPSILON，再取。

4. 判定两个数字相等，可以使用Math.abs(left - right) < Number.EPSILON

5. 实在不会，就直接用别人写好的成熟库吧。

参考资料：

https://betterprogramming.pub/why-is-0-1-0-2-not-equal-to-0-3-in-most-programming-languages-99432310d476
https://www.cnblogs.com/zhangycun/p/7880580.html
https://zh.wikipedia.org/zh-cn/IEEE_754
https://zhuanlan.zhihu.com/p/150291780
https://zhuanlan.zhihu.com/p/99082236
https://zhuanlan.zhihu.com/p/100353781

END