242 lines
7.7 KiB
Markdown
242 lines
7.7 KiB
Markdown
# 浮点数精度问题
|
||
|
||
|
||
|
||
## 经典真题
|
||
|
||
|
||
|
||
- 为什么 *console.log(0.2+0.1==0.3)* 得到的值为 *false*
|
||
|
||
|
||
|
||
## 浮点数精度常见问题
|
||
|
||
|
||
|
||
在 *JavaScript* 中整数和浮点数都属于 *number* 数据类型，所有数字都是以 *64* 位浮点数形式储存，即便整数也是如此。 所以我们在打印 *1.00* 这样的浮点数的结果是 *1* 而非 *1.00* 。
|
||
|
||
在一些特殊的数值表示中，例如金额，这样看上去有点别扭，但是至少值是正确了。
|
||
|
||
然而要命的是，当浮点数做数学运算的时候，你经常会发现一些问题，举几个例子：
|
||
|
||
**场景一**：进行浮点值运算结果的判断
|
||
|
||
```js
|
||
// 加法
|
||
console.log(0.1 + 0.2); // 0.30000000000000004
|
||
console.log(0.7 + 0.1); // 0.7999999999999999
|
||
console.log(0.2 + 0.4); // 0.6000000000000001
|
||
console.log(2.22 + 0.1); // 2.3200000000000003
|
||
|
||
// 减法
|
||
console.log(1.5 - 1.2); // 0.30000000000000004
|
||
console.log(0.3 - 0.2); // 0.09999999999999998
|
||
|
||
// 乘法
|
||
console.log(19.9 * 100); // 1989.9999999999998
|
||
console.log(19.9 * 10 * 10); // 1990
|
||
console.log(9.7 * 100); // 969.9999999999999
|
||
console.log(39.7 * 100); // 3970.0000000000005
|
||
|
||
// 除法
|
||
console.log(0.3 / 0.1); // 2.9999999999999996
|
||
console.log(0.69 / 10); // 0.06899999999999999
|
||
```
|
||
|
||
|
||
|
||
**场景二**：将小数乘以 *10* 的 *n* 次方取整
|
||
|
||
比如将钱币的单位，从元转化成分，经常写出来的是 *parseInt(yuan\*100, 10)*
|
||
|
||
```js
|
||
console.log(parseInt(0.58 * 100, 10)); // 57
|
||
```
|
||
|
||
|
||
|
||
**场景三**：四舍五入保留 *n* 位小数
|
||
|
||
例如我们会写出 *(number).toFixed(2)*，但是看下面的例子：
|
||
|
||
```js
|
||
console.log((1.335).toFixed(2)); // 1.33
|
||
```
|
||
|
||
在上面的例子中，我们得出的结果是 *1.33*，而不是预期结果 *1.34*。
|
||
|
||
|
||
|
||
## 为什么会有这样的问题
|
||
|
||
|
||
|
||
似乎是不可思议。小学生都会算的题目，*JavaScript* 不会？
|
||
|
||
我们来看看其真正的原因，到底为什么会产生精度丢失的问题呢？
|
||
|
||
|
||
|
||
计算机底层只有 *0* 和 *1*， 所以所有的运算最后实际上都是二进制运算。
|
||
|
||
十进制整数利用辗转相除的方法可以准确地转换为二进制数，但浮点数呢？
|
||
|
||
|
||
|
||
<img src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9fc493d0e2e84274b8445d8c5df405ae~tplv-k3u1fbpfcp-watermark.awebp" alt="img" style="zoom:50%;" />
|
||
|
||
|
||
|
||
*JavaScript* 里的数字是采用 *IEEE 754* 标准的 *64* 位双精度浮点数。
|
||
|
||
先看下面一张图：
|
||
|
||
|
||
|
||
该规范定义了浮点数的格式，对于 *64* 位的浮点数在内存中的表示，最高的 *1* 位是符号位，接着的 *11* 位是指数，剩下的 *52* 位为有效数字，具体如下：
|
||
|
||
- 符号位 *S*：第 *1* 位是正负数符号位（*sign*），*0* 代表正数，*1* 代表负数
|
||
- 指数位 *E*：中间的 *11* 位存储指数（*exponent*），用来表示次方数
|
||
- 尾数位 *M*：最后的 *52* 位是尾数（*mantissa*），储存小数部分，超出的部分自动进一舍零
|
||
|
||
也就是说，浮点数最终在运算的时候实际上是一个符合该标准的二进制数
|
||
|
||
符号位决定了一个数的正负，指数部分决定了数值的大小，小数部分决定了数值的精度。
|
||
|
||
*IEEE 754* 规定，有效数字第一位默认总是 *1*，不保存在 *64* 位浮点数之中。也就是说，有效数字总是 *1.xx…xx* 的形式，其中 *xx…xx* 的部分保存在 *64* 位浮点数之中，最长可能为 *52* 位。因此，*JavaScript* 提供的有效数字最长为 *53* 个二进制位（*64* 位浮点的后 *52* 位 + 有效数字第一位的 *1*）。
|
||
|
||
既然限定位数，必然有截断的可能。
|
||
|
||
|
||
|
||
我们可以看一个例子：
|
||
|
||
```js
|
||
console.log(0.1 + 0.2); // 0.30000000000000004
|
||
```
|
||
|
||
为了验证该例子，我们得先知道怎么将浮点数转换为二进制，整数我们可以用除 *2* 取余的方式，小数我们则可以用乘 *2* 取整的方式。
|
||
|
||
|
||
|
||
*0.1* 转换为二进制：
|
||
|
||
*0.1 \* 2*，值为 *0.2*，小数部分 *0.2*，整数部分 *0*
|
||
|
||
*0.2 \* 2*，值为 *0.4*，小数部分 *0.4*，整数部分 *0*
|
||
|
||
*0.4 \* 2*，值为0.8，小数部分0.8，整数部分0
|
||
|
||
*0.8 \* 2*，值为 *1.6*，小数部分 *0.6*，整数部分 *1*
|
||
|
||
*0.6 \* 2*，值为 *1.2*，小数部分 *0.2*，整数部分 *1*
|
||
|
||
*0.2 \* 2*，值为 *0.4*，小数部分 *0.4*，整数部分 *0*
|
||
|
||
从 *0.2* 开始循环
|
||
|
||
|
||
|
||
*0.2* 转换为二进制可以直接参考上述，肯定最后也是一个循环的情况
|
||
|
||
|
||
|
||
所以最终我们能得到两个循环的二进制数：
|
||
|
||
*0.1：0.0001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1100 ...*
|
||
|
||
*0.2：0.0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 0011 ...*
|
||
|
||
这两个的和的二进制就是：
|
||
|
||
*sum：0.0100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 ...*
|
||
|
||
最终我们只能得到和的近似值（按照 *IEEE 754* 标准保留 *52* 位，按 *0* 舍 *1* 入来取值），然后转换为十进制数变成：
|
||
|
||
sum ≈ 0.30000000000000004
|
||
|
||
|
||
|
||
再例如：
|
||
|
||
```js
|
||
console.log((1.335).toFixed(2)); // 1.33
|
||
```
|
||
|
||
因为 *1.335* 其实是 *1.33499999999999996447286321199*，*toFixed* 虽然是四舍五入，但是是对 *1.33499999999999996447286321199* 进行四五入，所以得出 *1.33*。
|
||
|
||
|
||
|
||
在 *Javascript* 中，整数精度同样存在问题，先来看看问题：
|
||
|
||
```js
|
||
console.log(19571992547450991); // 19571992547450990
|
||
console.log(19571992547450991===19571992547450992); // true
|
||
```
|
||
|
||
|
||
|
||
同样的原因，在 *JavaScript* 中 *number* 类型统一按浮点数处理，整数是按最大 *54* 位来算，
|
||
|
||
- 最大( *2<sup>53</sup> - 1*，*Number.MAX_SAFE_INTEGER*、*9007199254740991*)
|
||
- 最小( *-(2<sup>53</sup> - 1)*，*Number.MIN_SAFE_INTEGER*、*-9007199254740991*)
|
||
|
||
所以只要超过这个范围，就会存在被舍去的精度问题。
|
||
|
||
|
||
|
||
当然这个问题并不只是在 *Javascript* 中才会出现，几乎所有的编程语言都采用了 *IEEE-754* 浮点数表示法，任何使用二进制浮点数的编程语言都会有这个问题。
|
||
|
||
只不过在很多其他语言中已经封装好了方法来避免精度的问题，而 *JavaScript* 是一门弱类型的语言，从设计思想上就没有对浮点数有个严格的数据类型，所以精度误差的问题就显得格外突出。
|
||
|
||
|
||
|
||
通常这种对精度要求高的计算都应该交给后端去计算和存储，因为后端有成熟的库来解决这种计算问题。
|
||
|
||
前端也有几个不错的类库：
|
||
|
||
|
||
|
||
***Math.js***
|
||
|
||
*Math.js* 是专门为 *JavaScript* 和 *Node.js* 提供的一个广泛的数学库。它具有灵活的表达式解析器，支持符号计算，配有大量内置函数和常量，并提供集成解决方案来处理不同的数据类型。
|
||
|
||
像数字，大数字（超出安全数的数字），复数，分数，单位和矩阵。 功能强大，易于使用。
|
||
|
||
|
||
|
||
***decimal.js***
|
||
|
||
为 *JavaScript* 提供十进制类型的任意精度数值。
|
||
|
||
|
||
|
||
***big.js***
|
||
|
||
不仅能够支持处理 *Long* 类型的数据，也能够准确的处理小数的运算。
|
||
|
||
|
||
|
||
## 真题解答
|
||
|
||
|
||
|
||
- 为什么 *console.log(0.2+0.1==0.3)* 得到的值为 *false*
|
||
|
||
> 参考答案：
|
||
>
|
||
> 因为浮点数的计算存在 *round-off* 问题，也就是浮点数不能够进行精确的计算。并且：
|
||
>
|
||
> - 不仅 *JavaScript*，所有遵循 *IEEE 754* 规范的语言都是如此；
|
||
> - 在 *JavaScript* 中，所有的 *Number* 都是以 *64-bit* 的双精度浮点数存储的；
|
||
> - 双精度的浮点数在这 *64* 位上划分为 *3* 段，而这 *3* 段也就确定了一个浮点数的值，*64bit* 的划分是“*1-11-52*”的模式，具体来说：
|
||
> - 就是 *1* 位最高位（最左边那一位）表示符号位，*0* 表示正，*1* 表示负；
|
||
> - *11* 位表示指数部分；
|
||
> - *52* 位表示尾数部分，也就是有效域部分
|
||
|
||
|
||
|
||
-*EOF*-
|
||
|