该死的IEEE-754浮点数，说「约」就「约」，你的底线呢？以JS的名义来好好查查你

时间  2019-11-12
标签 该死 ieee 浮点数 底线 名义 好好 查查 栏目 JavaScript 繁體版
原文   原文链接

IEEE 754 表示：你尽管抓狂、骂娘，但你能彻底避开我，算我输。javascript

1、IEEE-754浮点数捅出的那些娄子

首先咱们仍是来看几个简单的问题，能说出每个问题的细节的话就能够跳过了，而若是只能泛泛说一句“由于IEEE754浮点数精度问题”，那么下文仍是值得一看。html

第一个问题是知名的0.1+0.2 != 0.3，为何？菜鸟会告诉你“由于IEEE 754的浮点数表示标准”，老鸟会补充道“0.1和0.2不能被二进制浮点数精确表示，这个加法会使精度丧失”，巨鸟会告诉你整个过程是怎样的，小数加法精度可能在哪几步丧失，你能答上细节么？前端

第二个问题，既然十进制0.1不能被二进制浮点数精确存储，那么为何console.log(0.1)打印出来的确确实实是0.1这个精确的值？java

第三个问题，你知道这些比较结果是怎么回事么？程序员

//这相等和不等是怎么回事？
0.100000000000000002 ==
0.100000000000000010 // true

0.100000000000000002 ==
0.100000000000000020 // false

//显然下面的数值没有超过Number.MAX_SAFE_INTEGER的范围，为何是这样？
Math.pow(10, 10) + Math.pow(10, -7) === Math.pow(10, 10) //  true
Math.pow(10, 10) + Math.pow(10, -6) === Math.pow(10, 10) //  false

追问一句，给出一个数，给这个数加一个增量，再和这个数比较，要保持结果是true，即相等，那么大约这个增量的数量级最大能够到多少，你能估计出来么？segmentfault

第四个问题，旁友，你知道下面这段一直在被引用的的代码么（这段代码用于解决常见范围内的小数加法以符合常识，好比将0.1+0.2结果精确计算为0.3）？你理解这样作的思路么？可是你知道这段代码有问题么？好比你计算268.34+0.83就会出现问题。安全

//注意函数接受两个string形式的数
function numAdd(num1/*:String*/, num2/*:String*/) { 
    var baseNum, baseNum1, baseNum2; 
    try { 
        baseNum1 = num1.split(".")[1].length; 
    } catch (e) { 
        baseNum1 = 0; 
    } 
    try { 
        baseNum2 = num2.split(".")[1].length; 
    } catch (e) { 
        baseNum2 = 0;
    } 
    baseNum = Math.pow(10, Math.max(baseNum1, baseNum2)); 
    return (num1 * baseNum + num2 * baseNum) / baseNum; 
};

//看上去好像解决了0.1+0.2
numAdd("0.1","0.2"); //返回精确的0.3

//可是你试试这个
numAdd("268.34","0.83");//返回 269.16999999999996

那么多问题，还真是该死的IEEE-754，而这一切都源于IEEE-754浮点数自己的格式，以及“说「约」就「约」”（舍入）的规则，导致精度丧失，计算沦丧，做为一个前端，咱们就从JS的角度来扒一扒。wordpress

2、端详一下IEEE-754双精度浮点的样貌

所谓“知己知彼，百战不殆”，要从内部瓦解敌人，就要先了解敌人，但为何只选择双精度呢，由于知道了双精度就明白了单精度，并且在JavaScript中，全部的Number都是以64-bit的双精度浮点数存储的，因此咱们来回顾一下究竟是怎么存储的，以及这样子存储怎么映射到具体的数值。函数

IEEE754浮点数形式

二进制在存储的时候是以二进制的“科学计数法”来存储的，咱们回顾下十进制的科学计数法，好比54846.3，这个数咱们在用标准的科学计数法应该是这样的：5.48463e4，这里有三部分，第一是符号，这是一个正数，只是通常省略正号不写，第二是有效数字部分，这里就是5.48463，最后是指数部分，这里是4。以上就是在十进制领域下的科学计数法，换到二进制也是同样，只是十进制下以10为底，二进制以2为底。工具

双精度的浮点数在这64位上划分为3段，而这3段也就肯定了一个浮点数的值，64bit的划分是“1-11-52”的模式，具体来讲：

  • 就是1位最高位（最左边那一位）表示符号位，0表示正，1表示负
  • 接下去11位表示指数部分
  • 最后52位表示尾数部分，也就是有效域部分

这里幺蛾子就不少了。首先“每一个实数都有一个相反数”这是中学教的，因而符号位改变下就是一个相反数了，可是对于数字0来讲，相反数就是本身，而符号位对于每个由指数域和尾数域肯定的数都是一视同仁，有正就有负，要么都没有。因此这里就有正0和负0的概念，可是正0和负0是相等的，可是他们能反应出符号位的不一样，和正零、负零相关的有意思的事这里不赘述。

而后，指数不必定要正数吧，能够是负数吧，一种方式是指数域部分也设置一个符号位，第二种是IEEE754采起的方式，设置一个偏移，使指数部分永远表现为一个非负数，而后减去某个偏移值才是真实的指数，这样作的好处是能够表现一些极端值，咱们等会会看到。而64bit的浮点数设置的偏移值是1023，由于指数域表现为一个非负数，11位，因此 0 <= e <= 2^11 -1，实际的E=e-1023，因此 -1023 <= E <= 1024。这两端的两个极端值结合不一样的尾数部分表明了不一样的含义。

最后，尾数部分，也就是有效域部分，为何叫有效域部分，举个栗子，这里有52个坑，可是你的数字由60个二进制1组成，无论怎样，你都是不能彻底放下的，只能放下52个1，那剩下的8个1呢？要么舍入要么舍弃了，总之是无效了。因此，尾数部分决定了这个数的精度。

而对于二进制的科学计数法，若是保持小数点前必须有一位非0的，那有效域是否是必然是1.XXXX的形式？而这样子的二进制被称为规格化的，这样的二进制在存储时，小数点前的1是默认存在，可是默认不占坑的，尾数部分就存储小数点后的部分。

问题来了，若是这个二进制小数过小了，那么会出现什么状况呢？对于一个接近于0的二进制小数，一味追求1.xxx的形式，必然致使指数部分会向负无穷靠拢，而真实的指数部分最小也就能表示-1023，一旦把指数部分逼到了-1023，尚未到1.xxx的形式，那么只能用0.xxx的形式表示有效部分，这样的二进制浮点数表示非规格化的。

因而，咱们整一个64位浮点数能表示的值由符号位s，指数域e和尾数域f肯定以下，从中咱们能够看到正负零、规格化和非规格化二进制浮点数、正负无穷是怎么表示的：

浮点数形式和数值的映射

这里的(0.f)和(1.f)指的是二进制的表示，都要转化为十进制再去计算，这样你就能够获得最终值。

回顾了IEEE754的64bit浮点数以后，有如下3点须要牢记的：

  1. 指数和尾数域是有限的，一个是11位，一个是52位
  2. 符号位决定正负，指数域决定数量级，尾数域决定精度
  3. 全部数值的计算和比较，都是这样以64个bit的形式来进行的，抛开脑海中想固然的十进制

3、精度在哪里发生丢失

当你直接计算0.1+0.2时，你要知道“你大妈已经不是你大妈，你大爷也已经不是你大爷了，因此他们生的孩子（结果）出现问题就能够理解了”。这里的0.1和0.2是十进制下的0.1和0.2，当它们转化为二进制时，它们是无限循环的二进制表示。

这引出第一处可能丢失精度的地方，即在十进制转二进制的过程当中丢失精度。由于大部分的十进制小数是不能被这52位尾数的二进制小数表示完毕的，咱们眼中最简单的0.一、0.2在转化为二进制小数时都是无限循环的，还有些可能不是无限循环的，可是转化为二进制小数的时候，小数部分超过了52位，那也是放不下的。

那么既然只有52位的有效域，那么必然超出52位的部分会发生一件灵异事件——阉割，文明点叫“舍入”。IEEE754规定了几种舍入规则，可是默认的是舍入到最接近的值，若是“舍”和“入”同样接近，那么取结果为偶数的选择。

因此上面的0.1+0.2中，当0.1和0.2被存储时，存进去的已经不是精确的0.1和0.2了，而是精度发生必定丢失的值。可是精度丢失尚未完，当这个两个值发生相加时，精度还可能进一步丢失，注意几回精度丢失的叠加不必定使结果误差愈来愈大哦。

第二处可能丢失精度的地方是浮点数参与计算时，浮点数参与计算时，有一个步骤叫对阶，以加法为例，要把小的指数域转化为大的指数域，也就是左移小指数浮点数的小数点，一旦小数点左移，必然会把52位有效域的最右边的位给挤出去，这个时候挤出去的部分也会发生“舍入”。这就又会发生一次精度丢失。

因此就0.1+0.2这个例子精度在两个数转为二进制过程当中和相加过程当中都已经丢失了精度，那么最后的结果有问题，不能如愿也就不奇怪了，若是你很想探究具体这是怎么计算的，文末附录的连接能帮助你。

4、疑惑：0.1不能被精确表示，但打印0.1它就是0.1啊

是的，照理说，0.1不能被精确表示，存储的是0.1的一个近似值，那么我打印0.1时，好比console.log(0.1)，就是打印出了精确的0.1啊。

事实是，当你打印的时候，其实发生了二进制转为十进制，十进制转为字符串，最后输出的。而十进制转为二进制会发生近似，那么二进制转为十进制也会发生近似，打印出来的值实际上是近似过的值，并非对浮点数存储内容的精确反映。

关于这个问题，StackOverflow上有一个回答能够参考，回答中指出了一篇文献，有兴趣的能够去看：

How does javascript print 0.1 with such accuracy?

5、相等不相等，就看这64个bit

再次强调，全部数值的计算和比较，都是这样以64个bit的形式来进行的，当这64个bit容不下时，就会发生近似，一近似就发生意外了。

有一些在线的小数转IEEE754浮点数的应用对于验证一些结果仍是颇有帮助的，你能够用这个IEEE-754 Floating-Point Conversion工具帮你验证你的小数转化为IEEE754浮点数以后是怎么个鬼样。

来看第一部分中提出两个简单的比较问题：

//这相等和不等是怎么回事？
0.100000000000000002 ==
0.1  //true

0.100000000000000002 ==
0.100000000000000010 // true

0.100000000000000002 ==
0.100000000000000020 // false

当你把0.1、0.100000000000000002、0.10000000000000001和0.10000000000000002用上面的工具转为浮点数后，你会发现，他们的尾数部分（注意看尾数部分最低4位，其他位都是相同的），前三个是相同的，最低4位是1010，可是最后一个转化为浮点数尾数最低4位是1011。

这是由于它们在转为二进制时要舍入部分的不一样可能形成的不一样舍入致使在尾数上可能呈现不一致，而比较两个数，本质上是比较这两个数的这64个bit，不一样便是不等的，有一个例外，+0==-0。

再来看提到的第二个相等问题：

Math.pow(10, 10) + Math.pow(10, -7) === Math.pow(10, 10) //  true
Math.pow(10, 10) + Math.pow(10, -6) === Math.pow(10, 10) //  false

为何上面一个是能够相等的，下面一个就不行了，首先咱们来转化下：

Math.pow(10, 10) =>
指数域 e =1056 ，即 E = 33
尾数域 (1.)0010101000000101111100100000000000000000000000000000

Math.pow(10, -7) =>
指数域 e =999 ，即 E = -24

Math.pow(10, -6) =>
指数域 e =1003 ，即 E = -20
尾数域 (1.)0000110001101111011110100000101101011110110110001101

能够看到1e10的指数是33次，而Math.pow(10, -7)指数是-24次，相差57次，远大于52，所以，相加时发生对阶，早就把Math.pow(10, -7)近似成0了。

而Math.pow(10, -6)指数是-20次，相差53次，看上去大于52次，但有一个默认的前导1别忘了，因而当发生对阶，小数点左移53位时，这一串尾数（别忘了前导1）正好被挤出第52位，这时候就会发生”舍入“，舍入结果是最低位，也就是bit0位变成1，这个时候和Math.pow(10, 10)相加，结果的最低位变成了1，天然和Math.pow(10, 10)不相等。

你能够用这个IEEE754计算器来验证结果。

6、浅析数值和数值精度的数量级对应关系

承接上面的那个结果，咱们发现当数值为10的10次时，加一个-7数量级的数，对于值没有影响，加一个-6数量级的数，却对值由影响，这里的本质咱们也是知道的：

这是因为计算时要对阶，若是一个小的增量在对阶时最高有效位右移（由于小数点在左移）到了52位开外，那么这个增量就极可能被忽略，即对阶完尾数被近似成0。

换句话说，咱们能够说对于10<sup>10</sup>数量级，其精确度大约在10<sup>-6</sup>数量级，那么对于10<sup>9</sup>、10<sup>8</sup>、10<sup>0</sup>等等数量级的值，精确度又大约在多少呢？

有一张图很好地说明了这个对应关系：

数值数量级和精确度数量级对应关系

这张图，横坐标表示浮点数值数量级，纵坐标表示能够到达的精度的数量级，固然这里横坐标对应的数值数量级指的是十进制表示下的数量级。

好比你在控制台测试（.toFixed()函数接受一个20及之内的整数n以显示小数点后n位）：

0.1.toFixed(20) ==> 0.10000000000000000555（这里也能够看出0.1是精确存储的），根据上面的图咱们知道0.1是10<sup>-1</sup>数量级的，那么精确度大约在10<sup>-17</sup>左右，而咱们验证一下:

//动10的-18数量级及以后的数字，并不会有什么，依旧断定相等
0.10000000000000000555 ==
0.10000000000000000999  //true
//动10的-17数量级上的数字，结果立刻不同了
0.10000000000000000555 ==
0.10000000000000001555  //false

从图上也能够看到以前的那个例子，10<sup>10</sup>数量级，精确度在10<sup>-6</sup>数量级。

也就是说，在IEEE754的64位浮点数表示下，若是一个数的数量级在10<sup>X</sup>，其精确度在10<sup>Y</sup>，那么X和Y大体知足：

X-16=Y

知道这个以后咱们再回过头来看ECMA在定义的Number.EPSILON，若是还不知道有这个的存在，能够控制台去输出下，这个数大约是10<sup>-16</sup>数量级的一个数，这个数定义为”大于1的能用IEEE754浮点数表示为数值的最小数与1的差值“，这个数用来干吗呢？

0.1+0.2-0.3<Number.EPSILON是返回true的，也就是说ECMA预设了一个精度，便于开发者使用，可是咱们如今能够知道这个预约义的值实际上是对应 10<sup>0</sup> 数量级数值的精确度，若是你要比较更小数量级的两个数，预约义的这个Number.EPSILON就不够用了（不够精确了），你能够用数学方式将这个预约义值的数量级进行缩小。

7、麻烦稍小的整数提供一种解决思路

那么怎样能在计算机中实现看上去比较正常和天然的小数计算呢？好比0.1+0.2就输出0.3。其中一个思路，也是目前足够应付大多数场景的思路就是，将小数转化为整数，在整数范围内计算结果，再把结果转化为小数，由于存在一个范围，这个范围内的整数是能够被IEEE754浮点形式精确表示的，换句话说这个范围内的整数运算，结果都是精确的，而大部分场景下这个数的范围已经够用，因此这种思路可行。

1. JS中数的“量程”和“精度”

之因此说一个范围，而不是全部的整数，是由于整数也存在精确度的问题，要深入地理解，”可表示范围“和”精确度“两个概念的区别，就像一把尺子的”量程“和”精度“。

JS所能表示的数的范围，以及能表示的安全整数范围（安全是指不损失精确度）由如下几个值界定：

//本身能够控制台打印看看
Number.MAX_VALUE => 能表示的最大正数，数量级在10的308次
Number.MIN_VALUE => 能表示的最小正数，注意不是最小数，最小数是上面那个取反，10的-324数量级

Number.MAX_SAFE_INTEGER => 能表示的最大安全数，9开头的16位数
Number.MIN_SAFE_INTEGER => 能表示的最小安全数，上面那个的相反数

为何超过最大安全数的整数都不精确了呢？仍是回到IEEE754的那几个坑上，尾数就52个坑，有效数再多，就要发生舍入了。

2. 一段有瑕疵的解决浮点计算异常问题的代码

所以，回到解决JS浮点数的精确计算上来，能够把待计算的小数转化为整数，在安全整数范围内，再计算结果，再转回小数。

因此有了下面这段代码（但这是有问题的）：

//注意要传入两个小数的字符串表示，否则在小数转成二进制浮点数的过程当中精度就已经损失了
function numAdd(num1/*:String*/, num2/*:String*/) { 
    var baseNum, baseNum1, baseNum2; 
    try { 
        //取得第一个操做数小数点后有几位数字，注意这里的num1是字符串形式的
        baseNum1 = num1.split(".")[1].length; 
    } catch (e) {
        //没有小数点就设为0 
        baseNum1 = 0; 
    } 
    try { 
        //取得第二个操做数小数点后有几位数字
        baseNum2 = num2.split(".")[1].length; 
    } catch (e) { 
        baseNum2 = 0;
    }
    //计算须要 乘上多少数量级 才能把小数转化为整数 
    baseNum = Math.pow(10, Math.max(baseNum1, baseNum2)); 
    //把两个操做数先乘上计算所得数量级转化为整数再计算，结果再除以这个数量级转回小数
    return (num1 * baseNum + num2 * baseNum) / baseNum; 
};

思路没有问题，看上去也解决了0.1+0.2的问题，用上面的函数计算numAdd("0.1","0.2")时，输出确实是0.3。可是再多试几个，好比numAdd("268.34","0.83")，输出是269.16999999999996，瞬间爆炸，这些代码一行都不想再看。

其实仔细分析一下，这个问题仍是很好解决的。问题是这么发生的，有一个隐式的类型转换，上面的num1和num2传入都是字符串类型的，可是在最后return的那个表达式中，直接参与计算，因而num1和num2隐式地从String转为Number，而Number是以IEEE754浮点数形式储存的，在十进制转为二进制过程当中，精度会损失。

咱们能够在上面代码的return语句之上加上这两句看看输出是什么：

console.log(num1 * baseNum);
console.log(num2 * baseNum);

你会发现针对numAdd("268.34","0.83")的例子，上面两行输出26833.999999999996、83。能够看到转化为整数的梦想并无被很好地实现

要解决这个问题也很容易，就是咱们显式地让小数“乖乖”转为整数，由于咱们知道两个操做数乘上计算所得数量级必然应该是一个整数，只是因为精度损失放大致使被近似成了一个小数，那咱们把结果保留到整数部分不就能够了么？

也就是把上面最后一句的

return (num1 * baseNum + num2 * baseNum) / baseNum; 改成 return (num1 * baseNum + num2 * baseNum).toFixed(0) / baseNum;

分子上的.toFixed(0)表示精确到整数位，这基于咱们明确地知道分子是一个整数。

3. 局限性和其余可能的思路

这种方式的局限性在于我要乘上一个数量级把小数转为整数，若是小数部分很长呢，那么经过这个方式转化出的整数就超过了安全整数的范围，那么计算也就不安全了。

不过仍是一句话，看使用场景进行选择，若是局限性不会出现或者出现了可是无伤大雅，那就能够应用。

另外一种思路是将小数转为字符串，用字符串去模拟，这样子作可适用的范围比较广，可是实现过程会比较繁琐。

若是你的项目中须要屡次面临这样的计算，又不想本身实现，那么也有现成的库可使用，好比math.js，感谢这个美好的世界吧。

8、小结

做为一个JS程序员，IEEE754浮点数可能不会常常让你心烦，可是明白这些能让你在之后遇到相关意外时保持冷静，正常看待。看彻底文，咱们应该能明白IEEE754的64位浮点数表示方式和对应的值，能明白精度和范围的区别，能明白精度损失、意外的比较结果都是源自于那有限数量的bit，而不用每次遇到相似问题就发一个日经的问题，不会就知道“IEEE754”这一个词的皮毛却说不出一句完整的表达，最重要是可以心平气和地骂一句“你这该死的IEEE754”后继续coding...

若有纰漏烦请留言指出，谢谢。

附：感谢如下内容对个人帮助

实现js浮点数加、减、乘、除的精确计算
IEEE-754 Floating-Point Conversion IEEE-754浮点数转换工具
IEEE754 浮点数格式 与 Javascript number 的特性
Number.EPSILON及其它属性

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程