一个关于js的加法问题:0.7+0.1=?
今天在写 JS 的时候无意中发现一个很有意思的问题:
>>> 0.7 + 0.1
0.7999999999999999
这个让我很诧异。另外我在 Python 和 Ruby 中试了一下,结果都是这个。
但是他们在计算
>>> 0.6 + 0.1
0.7
是正确的。 (当然以上只是部分例子。)
不知道各位有谁知道其中的原因。应该跟这些脚本语言处理浮点数的精度有关。现在先把问题贴出来,等明白了再来补充。
非常感谢各位的回答,迟了两天来解决这个问题,实在很抱歉。如同@比尔盖子所说的那样,我的确缺乏相关的浮点知识,于是这两天去看了一些相关的资料。回忆起了以前学习的知识。
再次感谢各位的回答。
Answers
提问者显然缺乏浮点数计算的基本知识。举几个例子:
>>> 0.125
0.12500000000000000
>>> 0.1
0.10000000000000001
>>> 0.6 + 0.1
0.69999999999999996
纳尼?什么会这样?
0.125
,也就是
1/8
,的二进制,是 0.001,可以在 10 进制和 2 进制中轻松表达。
但
0.1
就是一个经典的头疼数字了,它的二进制,是
0.00011001100110011001100110011001...
,一个无限循环小数。由于计算机中使用的浮点数是基于有限精度的二进制数,因此,不可能绝对准确。这一现象往往在打印浮点数时才被注意到。
浮点数的二进制表示,一般采用 IEEE 754 标准。标准规定:单精度格式具有 24 位有效数字,共 32 位。双精度格式具有 53 位有效数字精度,并 64 位。
但是,如今的解释器和
print
函数都足够聪明,会在打印浮点数的时候
自动舍入
,但是又有一些浮点数由于误差过大,又
不能舍入
。
因此造成了“有些浮点数计算是对的,有些是错的”的现象。事实上,所有的浮点数运算都是“错”的。也就是你问题的答案 。同时,这可能会成为 调试程序的烟幕弹 :“哎?print 出来 就是 0.1,为什么计算的时候会 出现问题 ?”
例如,新版本的 Python 默认对 所有的浮点数进行自动舍入 。因此无法重现我在文首的例子。这时,可以使用
>>> print("%.17lf" % (0.6 + 0.1))
0.69999999999999996
同理,浮点数之间用
>
,
<
,
==
来比较大小是不可取的。需要看两个浮点数是否在合理的误差范围,如果误差合理,即认为相等。
另外一个陷阱是,浮点数的误差会累积。
x = 0.0
for i in range(100):
x += 0.1
print("%.17lf" % x) #=> 9.99999999999998046
print(x) #=> 9.99999999999998 (Python 3),print 自动舍入,但比较保守
#=> 10.0 (Python 2),依然自动舍入,较激进,得到了看似正确的结果
在一般计算中,处理二进制浮点数需要用到很多技巧和技术。但在财务等运算中,必须要求完全精确的结果,这时候,需要模拟 10 进制的浮点数。如 Python 中提供了
Decimal
模块,允许使用者传入浮点数的字符串进行模拟计算,避免精度问题。
from decimal import Decimal
x = Decimal("0.0") # 注意:传入字符串。如果传入浮点数,那么在计算之前精度就损失掉了
for i in range(100):
x += Decimal("0.1")
print("%.17lf" % x) #=> 10.00000000000000000
print(x) #=> 10.0
但是,这种计算方式是模拟计算,
很慢
!比直接通过 CPU 进行的计算速度,大约
慢 1000 倍
。因此,只有财务等
确实
有必要的领域才用
Decimal
。不要使用
Decimal
做密集型数值运算,更不要将所有的浮点数运算替换为
Decimal
。
任何语言提供的类似模块同理
。
关于 IEEE 浮点数,浮点数的大小比较等具体算法和细节,可以观看网易上麻省理工学院的这一集课程: http://v.163.com/movie/2010/6/4/1/M6TCSIN1U_M6TCT0L41.html ,可以从 05:39 处开始观看。