js中浮点运算的坑 js定义浮点型

js中为什么eval("1*0.2+2*0.2+0*0.6")的结果是0.6000000000000001呢？

在IE8下是得到0.6的，在chrom 和Firefox下是0.6000000000000001。

其实这是js作浮点运算的一个bug，在JavsScript中，变量在存储时并不区分number和float类型，而是统一按float存储。而javascript使用IEEE 754-2008 标准定义的64bit浮点格式存储number，按照IEEE 754的定义：  

decimal64对应的整形部分长度为10,小数部分长度为16，所以默认的计算结果为“7.0000000000000001”，如最后一个小数为0，则取1作为有效数字标志。

解决方案：【注：以下代码并非原创】

(1).mul(0.2)+(2).mul(0.2)+0*0.6

script

//加法函数，用来得到精确的加法结果

//说明：javascript的加法结果会有误差，在两个浮点数相加的时候会比较明显。这个函数返回较为精确的加法结果。

//调用：accAdd(arg1,arg2)

//返回值：arg1加上arg2的精确结果

function accAdd(arg1,arg2){

    var r1,r2,m;

    try{r1=arg1.toString().split(".")[1].length}catch(e){r1=0}

    try{r2=arg2.toString().split(".")[1].length}catch(e){r2=0}

    m=Math.pow(10,Math.max(r1,r2))

    return (arg1*m+arg2*m)/m

}

//给Number类型增加一个add方法，调用起来更加方便，以下类似

Number.prototype.add = function (arg){

    return accAdd(arg,this);

}

Number.prototype.mul = function (arg){

    return accMul(arg,this);

}

//乘法函数，用来得到精确的乘法结果

//说明：javascript的乘法结果会有误差，在两个浮点数相乘的时候会比较明显。这个函数返回较为精确的乘法结果。

//调用：accMul(arg1,arg2)

//返回值：arg1乘以arg2的精确结果

function accMul(arg1,arg2)

{

    var m=0,s1=arg1.toString(),s2=arg2.toString();

    try{m+=s1.split(".")[1].length}catch(e){}

    try{m+=s2.split(".")[1].length}catch(e){}

    return Number(s1.replace(".",""))*Number(s2.replace(".",""))/Math.pow(10,m)

}

Number.prototype.div = function (arg){

    return accDiv(arg,this);

}

//除法函数，用来得到精确的除法结果

//说明：javascript的除法结果会有误差，在两个浮点数相除的时候会比较明显。这个函数返回较为精确的除法结果。

//调用：accDiv(arg1,arg2)

//返回值：arg1除以arg2的精确结果

function accDiv(arg1,arg2){

    var t1=0,t2=0,r1,r2;

    try{t1=arg1.toString().split(".")[1].length}catch(e){}

    try{t2=arg2.toString().split(".")[1].length}catch(e){}

    with(Math){

        r1=Number(arg1.toString().replace(".",""))

        r2=Number(arg2.toString().replace(".",""))

        return (r1/r2)*pow(10,t2-t1);

    }

}

/script

相关问答

Q1: js浮点数的加减乘除解决方案

一直知道js的浮点数计算是不精确的， 0.1 + 0.2 !== 0.3，但是也就知道而已，解决方法却不怎么注意，所以刚做一个项目，尽管了解浮点数精度不精确的问题，但是还是掉坑里了。在此再次默默告诉自己要警惕，端正心态，不可掉以轻心！！！所以下面就分享一些加减乘除的方法。

原理： 把数字转换成字符串，然后从小数点部分切割成两部分，分别算出两个因数的小数点右边的长度，然后用两个因数的小数点右边长度最大的数再乘以10，相当于两个都放大了n倍，然后相加，然后缩小n倍。

注意，这里的放大用了乘法times函数（下面介绍），因为浮点数直接乘以100有可能出现精度不够的情况，如下图

原理和加法一样，放大n倍后相减再缩小n倍

乘法原理稍微变点，放大倍数n是 ‘两个小数点后面长度之和’ 而不是 ‘两个小数点后面长度这两者之间的最大值’

除法原理和乘法一样

这也是一个坑，比如你要保留两位小数，四舍五入的话就要看小数点第三位后面的数字来决定，如2.445四舍五入后就是2.45； 2.444四舍五入就是2.44；做这个需求的时候，我第一反应是Math.toFixed(2)，结果是bug百出啊，这里就不举例了，有兴趣可以自己尝试。然后我是怎么解决的呢？百度了一下，也是得到一些半成品不严谨的函数，原理也很简单，先放大倍数，然后利用Math.round()取整

以上加减乘除方法基本满足一般业务需求了，尤其是电商。但是如果数字计算时超出了 2的1024次方减1 ，也就是 9007199254740992 这个数字的话就不适合了，因为从 2^1024 开始就变成了 Infinity。

Q2: js中浮点计算错误原因及解决办法

经典的好家伙（典型的错误）：

借用大佬的方法（原理是将浮点数变为整数，之所以用这位大佬，是因为他包含了对超大值的判断 即56.3e-12）

错误原因：因为使用了IEEE754数值，这种错误并非js独有，其他使用相同格式的语言也有这个问题（如c，java，python等）

Q3: JS位运算异常（位运算精度丢失）的原因探究

《【转+补充】深入研究js中的位运算及用法》

《【JS时间戳】获取时间戳的最快方式探究》

日常开发中一直没遇到过位运算导致精度丢失的问题，直到这天，搞10位时间戳取整的时候，终于被我撞上了。具体是个什么场景呢，我们来还原下案发现场：

可以看到输出的结果为：

得到的 t 是一个精确到微秒的时间戳。但是请求接口的时候需要的是一个10位（精确到秒）的时间戳，所以这里需要将它转换为10位，自然就是 ➗1000 即可，然后通过位运算来实现类似 Math.trunc 的取证效果，得到了我们要的10位时间戳。至此完美解决！那问题又是如何发生的呢？

按照上面的运算规律，如果我们要获取13位时间戳，是不是直接对 t0 就可以了呢？我们来看一下：

输出结果如下：

WTF!!!看到了咩！！！居然输出了一个负数！！！我们想要的结果应该是 1597113682985 才对啊！为什么会出现了负数呢！！！

由此，怪物出现啦！我们今天就来解读（xiang fu)一下它！

想到这里，我们一定就会怪是位运算的锅！那这个锅该怎么让位运算背起来呢！我们来研究一下！

首先我们知道，JS中没有真正的整型，数据都是以double(64bit)的标准格式存储的，这里就不再赘述了，要想搞透其中的原理，请打开 【传送门】

位运算是在数字底层（即表示数字的 32 个数位）进行运算的。由于位运算是低级的运算操作，所以速度往往也是最快的（相对其它运算如加减乘除来说），并且借助位运算有时我们还能实现更简单的程序逻辑,缺点是很不直观，许多场合不能够使用。

以下来源于w3shool:

ECMAScript 整数有两种类型，即有符号整数（允许用正数和负数）和无符号整数（只允许用正数）。 在 ECMAScript 中，所有整数字面量默认都是有符号整数 ，这意味着什么呢？

有符号整数使用 31 位表示整数的数值，用第 32 位表示整数的符号，0 表示正数，1 表示负数。数值范围从 -2147483648 到 2147483647 。

可以以两种不同的方式存储二进制形式的有符号整数，一种用于存储正数，一种用于存储负数。 正数是以真二进制形式存储的 ，前 31 位中的每一位都表示 2 的幂，从第 1 位（位 0）开始，表示 20，第 2 位（位 1）表示 21。没用到的位用 0 填充，即忽略不计。例如，下图展示的是数 18 的表示法。

那在js中二进制和十进制如何转换呢？如下

负数同样以二进制存储，但使用的格式是二进制补码。计算一个数值的二进制补码，需要经过下列3个步骤：

例如，要确定-18的二进制表示，首先必须得到18的二进制表示，如下所示：

0000 0000 0000 0000 0000 0000 0001 0010

接下来，计算二进制反码，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101

最后，在二进制反码上加 1，如下所示：

1111 1111 1111 1111 1111 1111 1110 1101 +

0000000000000000000000000000 0001 =

1111 1111 1111 1111 1111 1111 1110 1110

因此，-18 的二进制就是 1111 1111 1111 1111 1111 1111 1110 1110

而其相反数18的二进制为 0000 0000 0000 0000 0000 0000 0001 0010

ECMAScript会尽力向我们隐藏所有这些信息，在以二进制字符串形式输出一个负数时，我们看到的只是这个负数绝对值的二进制码前面加上了一个负号

JavaScript 只有一种数字类型 ( Number )

我们将 1596596596.3742654.toString(2) 转为二进制字符串表示如下：

1011111001010100010000101110100.0101111111001111110111

但实际在内存中的存储如下：

说到这里就不得不简单提一下数字精度丢失的问题。上面也知道，JS中所有的数字都是用double方式进行存储的，所以必然会存在精度丢失问题。

以下转自文章： JavaScript数字精度丢失问题总结

此时只能模仿十进制进行四舍五入了，但是二进制只有 0 和 1 两个，于是变为 0 舍 1 入。这即是计算机中部分浮点数运算时出现误差，丢失精度的根本原因。

大整数的精度丢失和浮点数本质上是一样的，尾数位最大是 52 位，因此 JS 中能精准表示的最大整数是 Math.pow(2, 53) ，十进制即 9007199254740992

大于 9007199254740992 的可能会丢失精度：

9007199254740992 10000000000000...000 ``// 共计 53 个 0

9007199254740992 + 1 10000000000000...001 ``// 中间 52 个 0

9007199254740992 + 2 10000000000000...010 ``// 中间 51 个 0

实际上

9007199254740992 + 1 ``// 丢失

9007199254740992 + 2 ``// 未丢失

9007199254740992 + 3 ``// 丢失

9007199254740992 + 4 ``// 未丢失

以上，可以知道看似有穷的数字, 在计算机的二进制表示里却是无穷的，由于存储位数限制因此存在“舍去”，精度丢失就发生了。

想了解更深入的分析可以看这篇论文（你品！你细品！）： What Every Computer Scientist Should Know About Floating-Point Arithmetic

关于精度和范围的内容可查看 【JS的数值精度和数值范围】

通过前面的知识补充，我们已经知道：

这也就是为什么对于整数部位为10位的时间戳，通过位运算可以进行取整（因为目前时间戳159xxxxxxx2147483647），不存在时间戳超过范围的问题。但是对于13位时间戳，如 15966154471232147483647 ，此时再通过位运算操作的时候就会导致异常，如：

这主要是因为在进行位运算之前，JS会先将64bit的浮点数 1596615447015.01 转为32bit的有符号整型后进行运算的，这个转换过程如下：

为了验证上述过程，我们再举一个例子： 1590015447015.123 0 = 877547495

将将将将！没错的吧！所以JS的这个坑还真是。。。 让人Orz

关于js中浮点运算的坑和js定义浮点型的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。