就在刚刚，果子学生信上推送了一篇
眼见不为实：为什么29不等于29？
，这里就从计算机存储原理上讲讲，为什么29不等于29.
我们可能都知道，计算机以二进制的方式存储数字，举两个例子：
对于整型的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，不会好奇为啥0.3不等于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)
还有kaopuber提到的
如何避免浮点数计算的坑
推荐阅读
-
眼见不为实：为什么29不等于29？
