JS计算误差小谈

平时在写js代码时会用到一些简单的计算，比方说系统中我们数据库储存的金额是分，前端展示的是元，所以在用户输入元之后要转成分传给后台，这个公式小学一年级就学过了

1	1.11*100 = 111

一般来说这个计算结果是没问题的，但是在js里面却有这样的尴尬

1	1.11*100 = 111.00000000000001

结果不是我们想要的111，类似的情况还有

0.1+0.2 = 0.30000000000000004   //加法
0.27-0.11 = 0.16000000000000003 //减法
19.9*100 = 1989.9999999999998   //乘法
0.3/0.1 = 2.9999999999999996    //除法

一般遇到这种问题，我们都有成熟的解决方案解决

用着用着就习惯了，一直没有搞清楚为什么会有这样的误差。这两天正好有空，看了一些博客终于搞清楚了。

双精度浮点数

JS 的数据类型比较特别，和C、Java 等语言的的数据类型不一样，不管是 int、double、float 在 JS 里面都是Number类型。
要搞清楚为什么有这个误差，就要先介绍一下双精度浮点(double)

双精度浮点数(double)使用 64 位（8字节）来储存一个浮点数。它可以表示十进位制的15或16位有效数字，其可以表示的数字的绝对值范围大约是 [2.23*10^(-308),1.79*10^(308)]。

这其中的64位bit又可以分为下面的格式

sign bit(符号位)：0代表正数，1代表负数
exponent(指数)：中间的11位用来表示次方数
mantissa(尾数)：最后的52位用来表示精确度

上面的格式可以转换成这个这个公式

在十进制中，整数部分可以是0~~9，在二进制中整数部分只能是0~~1，所以可以看到上面公式对应的整数部分只能是1，这样就可以不用管整数部分直接保留后面的小数部分就可以了。指数 exponent(E) 是一个无符号整型 (unsigned int) ，那么问题就来了，我们怎么保留小数呢？按照科学计数法，如果E小于0才可以表示成小数，因为E是11位的，最大可以表示为2047，所以取一个中间值1023（十六进制为ox3FF），0~~1022表示为负，1023~~2047表示为正，这样就解决了小数的表示问题。

我们来看看数字 1 是怎么储存的

用上面的公式表示就是：(-1)^0 * 2^(1024-1023) * 1.0 = 1，再看一下 0.5 的储存形式

(-1)^0 * 2^(1022-1023) * 1.0 = 0.5，搞清楚这个，我们再看看上面提到的 1.11*100 = 111.00000000000001 这个问题。

将 1.11 转换成二进制是这样的1.0001110000101000111101011100001010001111010111000011...(11100001010001111010循环)（十进制小数转二进制方法)，换成64位浮点来表示，S为0，E为1023，mantissa(M)为0001110000101000111101011100001010001111010111000011，因为位数只有52位，后面循环的部分就被舍弃了，转成64位浮点数是这样的

然后转成10进制的就变成了

1	1.11000000000000009769962616701

所以这里出现了问题，误差就有了，究其根本还是精度的问题。

还有一个问题？

为什么我直接输入 1.11 得到的结果是 1.11，而不是1.11000000000000009769962616701 呢？

这个还是精度问题，64位浮点的尾数是52位，因为整数部分只能是1所以可以省略一位，比方说

1 2	11.101 * 2^1001 可以格式化为 1.1101 * 2^1010，尾数部分M直接储存1101即可； 0.0011101 * 2^-1001 可以格式化为 1.1101 * 2^-1100，尾数部分M储存1101即可。

所以他可以表示的最大长度是53，即2^53 = 9007199254740992，所以双精度浮点能表示的最大精度是 16 位的，JS 会调用 toPrecision(16) 来做运算

1	1.11.toPrecision(16) = 1.110000000000000 //自动取整之后就是1.11

如果精度调整一下，结果就不一样了：

1 2	1.11.toPrecision(17) = 1.1100000000000001 1.11.toPrecision(20) = 1.1100000000000000977

到这里终于真相大白了！