序列和==操作符的神秘行为。精密的问题？(Mysterious behaviour of se

我遇到的函数的莫名其妙怪异（或只是没有预期？）的行为seq 。当创建一个简单的顺序一些值不能正确地与==操作符匹配。看到这个小例子：

my.seq <- seq(0, 0.4, len = 5)
table(my.seq)                  # ok! returns  0 0.1 0.2 0.3 0.4 
                               #              1   1   1   1   1 

which(my.seq == 0.2)           # ok! returns  3
which(my.seq == 0.3)           # !!! returns  integer(0)

当手动创建我的序列，它似乎工作，但：

my.seq2 <- c(0.00, 0.10, 0.20, 0.30, 0.40)

which(my.seq2 == 0.3)           # ok! returns  4

你有任何的解释？我解决了这个问题，通过使用which(round(my.seq, 2) == 0.3)但我会感兴趣的是什么引起的问题。

在此先感谢您的意见。

Answer 1:

计算机只是不代表浮点数好。电子表格隐藏此的一般倾向由作为主要方式大多数人处理电脑上的数字，导致很多问题。

决不对阵精确浮点值。有R中的函数来处理这个（如all.equal ），但我更喜欢以下。

假设你有一个未知的浮点变量A，你想看看它是否等于0.5。

abs(A - 0.5) < tol

设置宽容你如何接近需要它0.5。例如， tol <- 0.0001可能会替你安排。

如果你的价值观看起来像他们应该是整数刚轮。或者，如果你知道你要考到那么小数水平，你可以圆到小数点的水平。

Answer 2:

计算机有一个艰难的时间，存储精确值。

> options(digits=22)
> seq(0, .4, len = 5)
[1] 0.0000000000000000000000 0.1000000000000000055511 0.2000000000000000111022
[4] 0.3000000000000000444089 0.4000000000000000222045
> .4
[1] 0.4000000000000000222045
> c(0, .1, .2, .3, .4)
[1] 0.0000000000000000000000 0.1000000000000000055511 0.2000000000000000111022
[4] 0.2999999999999999888978 0.4000000000000000222045

由于我们使用一个二进制浮点表示，我们不能代表相关的值准确。它看起来因为对于.4值大于0.4，对于.3值比，如果你键入0.3本身高那么一点点高那么一点点。我敢肯定，别人会提供一个更好的解释这个，但希望这棚对这个问题的一些情况。