注意编程语言中浮点运算

我们可能都知道,计算机以二进制的方式存储数字,举两个例子:

对于整型的125,在十进制里是1*100 + 2*10+ 5*1,而对应的二进制形式是1111101(64 + 32 + 16 + 8 + 4 + 0 + 1)。

对于浮点型的0.125,在十进制里是1/10 + 2/100 + 5/1000,对应二进制下的0.001,即0/2 + 0/4 + 1/8。

在不溢出的情况下,基本上所有十进制上的整型都能无损转成二进制。但是对于浮点型,就不能保证所有十进制下的小数都能无损转成二进制的表示方式。举个例子,假如你要在二进制下表示0.1(1/10),已知0.1小于我们之前的0.125,因此它不能是0.001, 那么它是0.0001吗?然而0.0001对应的是1/16,也就是0.0625,比0.1小。0.00011对应0.9375, 稍微靠近了0.1,0.000111对应0.109375比0.1大,0.0001101对应0.1015625依旧比0.1大,0.00011001对应0.09765625又靠近了0.1。也就是说,0.1在二进制中这是一个无限循环小数。

0.0001100110011001100110011001100110011001100110011...

这就类似于试图用小数形式描述十进制下的1/3,只可能是0.3333333...。

循环是无限的,但是计算机存储是有限的,不能用有限的空间来存放无限的循环。因此对于不同编程语言,它们都会为不同的数据类型分配不同的内存大小。对于浮点数运算而言,基本上所有的编程语言都用的是IEEE 754标准。

例如Python而言的PEP 754就是关于它的浮点型存放方式。在R里面用?as.double查看帮助文档时也能发现R也遵从IEEE 754。这里不在拓展介绍这个标准,只是为了说明我们只能用有限的空间来存储无限循环的小数。因此,大部分的小数都可能不是你看到的样子。大部分的编程语言,其实都会在浮点型运算结果中给你体现出这种差异,比方说Python

>>> 0.1 + 0.2
0.30000000000000004

看到这个结果,你就会好奇为啥0.1+0.2的结果不是0.3,不会好奇为啥03不等于0.3。但是在R语言中,你会好奇为啥0.3不等于0.3, 因为明明看起来一样啊

> 0.1 + 0.2
[1] 0.3
> (0.1+0.2) == 0.3
[1] FALSE

如果你想看到它的实际值,就需要借助于sprint这个函数了

sprintf("%.20f", 0.1 + 0.2 )
[1] "0.30000000000000004441"

因此,在R语言做浮点运算时,一定要谨慎,可以考虑用Hadley开发的dplyr

library(dplyr)
near(0.1+0.2, 0.3)

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×