摘要:
由于计算机是用二进制来存储和处理数字,不能精确表示浮点数,而JavaScript中没有相应的封装类来处理浮点数运算,直接计算会导致运算精度丢失。
为了避免产生精度差异,把需要计算的数字升级(乘以10的n次幂)成计算机能够精确识别的整数,等计算完毕再降级(除以10的n次幂),这是大部分编程语言处理精度差异的通用方法。
关键词:
计算精度 四舍五入 四则运算 精度丢失
1. 疑惑
我们知道,几乎每种编程语言都提供了适合货币计算的类。例如C#提供了decimal,Java提供了BigDecimal,JavaScript提供了Number……
由于之前用decimal和BigDecimal用得很好,没有产生过精度问题,所以一直没有怀疑过JavaScript的Number类型,以为可以直接使用Number类型进行计算。但是直接使用是有问题的。
我们先看看四舍五入的如下代码:
由于计算机是用二进制来存储和处理数字,不能精确表示浮点数,而JavaScript中没有相应的封装类来处理浮点数运算,直接计算会导致运算精度丢失。
为了避免产生精度差异,把需要计算的数字升级(乘以10的n次幂)成计算机能够精确识别的整数,等计算完毕再降级(除以10的n次幂),这是大部分编程语言处理精度差异的通用方法。
关键词:
计算精度 四舍五入 四则运算 精度丢失
1. 疑惑
我们知道,几乎每种编程语言都提供了适合货币计算的类。例如C#提供了decimal,Java提供了BigDecimal,JavaScript提供了Number……
由于之前用decimal和BigDecimal用得很好,没有产生过精度问题,所以一直没有怀疑过JavaScript的Number类型,以为可以直接使用Number类型进行计算。但是直接使用是有问题的。
我们先看看四舍五入的如下代码:
按正常结果,应该分别弹出0.01和162.30。但实际测试结果却是在不同浏览器中得到的是不同的结果:
在ie6、7、8下得到0.00和162.30,第一个数截取不正确;
在firefox中得到0.01和162.29,第二个数截取不正确;
在opera下得到0.01和162.29,第二个数截取不正确
我们再来看看四则运算的代码:
按正常结果,除第一行外(因为其本身就不能除尽),其他都应该要得到精确的结果,从弹出的结果我们却发现不是我们想要的正确结果。是因为没有转换成Number类型吗?我们转换成Number后再计算看看:
还是一样的结果,看来javascript默认把数字识别为number类型。为了验证这一点,我们用typeof弹出类型看看:
2. 原因
为什么会产生这种精度丢失的问题呢?是javascript语言的bug吗?
我们回忆一下大学时学过的计算机原理,计算机执行的是二进制算术,当十进制数不能准确转换为二进制数时,这种精度误差就在所难免。
再查查javascript的相关资料,我们知道javascript中的数字都是用浮点数表示的,并规定使用IEEE 754 标准的双精度浮点数表示:
IEEE 754 规定了两种基本浮点格式:单精度和双精度。
IEEE单精度格式具有24 位有效数字精度(包含符号号),并总共占用32 位。
IEEE双精度格式具有53 位有效数字精度(包含符号号),并总共占用64 位。
这种结构是一种科学表示法,用符号(正或负)、指数和尾数来表示,底数被确定为2,也就是说是把一个浮点数表示为尾数乘以2的指数次方再加上符号。下面来看一下具体的规格:
符号位 | 指数位 | 小数部分 | 指数偏移量 | |
单精度浮点数 | 1位(31) | 8位(30-23) | 23位(22-00) | 127 |
双精度浮点数 | 1位(63) | 11位(62-52) | 52位(51-00) | 1023 |
我们以单精度浮点数来说明:
指数是8位,可表达的范围是0到255
而对应的实际的指数是-127到+128
这里特殊说明,-127和+128这两个数据在IEEE当中是保留的用作多种用途的
-127表示的数字是0
128和其他位数组合表示多种意义,最典型的就是NAN状态。
知道了这些,我们来模拟计算机的进制转换的计算,就找一个简单的0.1+0.2来推演吧:
从上述的推演过程我们知道,这种误差是难免的,c#的decimal和Java的BigDecimal之所以没有出现精度差异,只是因为在其内部作了相应处理,把这种精度差异给屏蔽掉了,而javascript是一种弱类型的脚本语言,本身并没有对计算精度做相应的处理,这就需要我们另外想办法处理了。
3. 解决办法
3.1 升级降级
从上文我们已经知道,javascript中产生精度差异的原因是计算机无法精确表示浮点数,连自身都不能精确,运算起来就更加得不到精确的结果了。那么怎么让计算机精确认识要计算的数呢?
我们知道十进制的整数和二进制是可以互相进行精确转换的,那么我们把浮点数升级(乘以10的n次幂)成计算机能够精确识别的整数来计算,计算完毕之后再降级(除以10的n次幂),不就得到精确的结果了吗?好,就这么办!
我们知道,Math.pow(10,scale)可以得到10的scale次方,那么就把浮点数直接乘以Math.pow(10,scale)就可以了吗?我最初就是这么想的,但后来却发现一些数字运算后实际结果与我们的猜想并不一致。我们来看看这个简单的运算:
按常理应该返回51206,但实际结果却是51205.99999999999。奇怪吧?其实也不奇怪,这是因为浮点数不能精确参与乘法运算,即使这个运算很特殊(只是乘以10的scale次方进行升级)。如此我们就不能直接乘以10的scale次方进行升级,那就让我们自己来挪动小数点吧。
怎么挪动小数点肯定大家是各有妙招,此处附上我写的几个方法:
这样我们升级降级都可以转换成字符串后调用String对象的自定义方法movePoint了,乘以10的scale次方我们传正整数scale,除以10的scale次方我们传负整数-scale。
再来看看我们之前升级512.06的代码,采用自定义方法的调用代码变成这样:
这样直接挪动小数点就不怕它不听话出现一长串数字了(*^__^*)。 当然,movePoint方法得到的结果是字符串,如果要转成Number类型也很方便(怎么转就不再废话了)。
3.2 四舍五入
好,有了升级降级的基础,我们来看看四舍五入的方法,由于不同浏览器对Number的toFixed方法有不同的支持,我们需要用自己的方法去覆盖浏览器的默认实现。
有一个简单的办法是我们自己来判断要截取数据的后一位是否大于等于5,然后进行舍或者入。我们知道Math.ceil方法是取大于等于指定数的最小整数,Math.floor方法是取小于等于指定数的最大整数,于是我们可以利用这两个方法来进行舍入处理,先将要进行舍入的数升级要舍入的位数scale(乘以10的scale次方),进行ceil或floor取整后,再降级要舍入的位数scale(除以10的scale次方)。
代码如下:
覆盖Number类型的toFixed方法后,我们再来执行以下方法
在ie6、7、8、firefox、Opera下分别进行验证,都能得到相应的正确的结果。
另一种方式是在网上找到的采用正则表达式来进行四舍五入,代码如下:
经验证,这两个方法都能够进行准确的四舍五入,那么采用哪个方法好呢?实践出真知,我们写一个简单的方法来验证一下两种方式的性能:
为了避免对同一个数字进行四舍五入运算有缓存问题,我们取当前毫秒数进行四舍五入。经验证,在同一台机器上运算10万次的情况下,用movePoint方法,平均耗时2500毫秒;用正则表达式方法,平均耗时4000毫秒。
3.3 加减乘除
对指定数字进行四舍五入可以通过floor/ceil或者正则表达式达到舍入的目的,那么四则运算是不是也可以升级成计算机能够精确识别的整数来计算,计算完毕再降级呢?这个答案是肯定的,我们先来看看加法:
这时候再执行之前的加法
alert(Number(0.1).add(0.2));//弹出0.3
这时候就可以计算出精确的结果了。
类似可以写出减法:
类似可以写出乘法:
类似可以写出除法:
重要提示:由于除法不能精确到几位小数,在计算完成的时候应根据需要进行适当的四舍五入,以避免产生精度差异。
4. 结论
由于计算机是用二进制来存储和处理数字,不能精确表示浮点数,因此这种精度差异几乎出现在所有的编程语言中(例如C/C++/C#,Java),准确的说:“使用了IEEE 754浮点数格式”来存储浮点类型(float 32,double 64)的任何编程语言都有这个问题!而C#、Java是因为提供了封装类decimal、BigDecimal来进行相应的处理才避开了这个精度差异。
为了避免产生精度差异,把需要计算的数字全升级(乘以10的n次幂)成计算机能够精确识别的整数,等计算完毕再降级(除以10的n次幂),这是大部分编程语言处理精度差异的通用方法。
对指定数字进行四舍五入可以通过floor/ceil或者正则表达式达到舍入的目的,那么四则运算是不是也可以升级成计算机能够精确识别的整数来计算,计算完毕再降级呢?这个答案是肯定的,我们先来看看加法:
这时候再执行之前的加法
alert(Number(0.1).add(0.2));//弹出0.3
这时候就可以计算出精确的结果了。
类似可以写出减法:
类似可以写出乘法:
类似可以写出除法:
重要提示:由于除法不能精确到几位小数,在计算完成的时候应根据需要进行适当的四舍五入,以避免产生精度差异。
4. 结论
由于计算机是用二进制来存储和处理数字,不能精确表示浮点数,因此这种精度差异几乎出现在所有的编程语言中(例如C/C++/C#,Java),准确的说:“使用了IEEE 754浮点数格式”来存储浮点类型(float 32,double 64)的任何编程语言都有这个问题!而C#、Java是因为提供了封装类decimal、BigDecimal来进行相应的处理才避开了这个精度差异。
为了避免产生精度差异,把需要计算的数字全升级(乘以10的n次幂)成计算机能够精确识别的整数,等计算完毕再降级(除以10的n次幂),这是大部分编程语言处理精度差异的通用方法。