R语言中round函数或/运算符是否存在Bug？

这绝对不是R的Bug，而是浮点数精度限制导致的常见问题——几乎所有编程语言都会遇到类似情况。

问题根源：二进制浮点数的存储特性 #

计算机用二进制存储浮点数，但很多十进制小数（比如55.8、1.8）转换成二进制后是无限循环的，无法被精确存储。当你计算55.8/1.8时，得到的结果并不是精确的31，而是一个非常接近31的近似值——只是R为了可读性，在显示时把它简化成了31。

我们可以用更精确的方式查看这个值：

sprintf("%.20f", 55.8/1.8)
# 输出："30.99999999999999644729"

看到了吗？实际值略小于31，而round(55.8/1.8)会把这个近似值四舍五入成精确的整数31，所以两者比较自然返回FALSE，差值就是那个极小的3.552714e-15（约3.55×10⁻¹⁵）。

如何正确处理这种情况？ #

如果你需要判断除法结果是否为整数，别直接用==比较浮点数，推荐两种方法：

• 使用R内置的all.equal()函数，它会自动考虑浮点数的微小误差：

  all.equal(round(55.8/1.8), 55.8/1.8)
  # 输出：TRUE
  

• 自定义一个误差阈值，判断两个值的差是否小于这个阈值（比如1e-10）：

  abs(round(55.8/1.8) - 55.8/1.8) < 1e-10
  # 输出：TRUE
  

这样就能避免因浮点数精度问题导致的错误判断了。

内容的提问来源于stack exchange，提问作者Nicola Dinapoli