R NA与NA匹配，但不等于NA。为什么？

在R语言定义中，

NA

值被简要描述，其中一部分表示

。。。特别是，

FALSE&NA

是

FALSE

，

TRUE | NA

是

TRUE

<代码>NA不等于 任何其他价值或对自身的价值；使用

is.NA

测试

NA

。但是，一个

NA

值将与

match

中的另一个

NA

值匹配

关于声明“

NA

不等于 任何其他值或其本身“

---

更新： 经再次修订的问题是：

在

匹配

匹配

中，以及该语言中其他地方的匹配背后的原因是什么

对于我来说，任何人都不知道的缺失值（或者它不会缺失）会与相同类型的另一个缺失值匹配是没有意义的。由于我发布了这篇文章，我在

example（match）

中遇到了一些推理。角色强制更改其类型。如果我愿意，我可以把它完全抹掉

match(NA, NA)
# [1] 1
match(NA, NA_real_)
# [1] 1
match(NA_character_, NA_real_)
# [1] 1
match(paste(NA), NA)
# [1] NA
gsub("NA", "", NA)
# [1] NA
gsub("NA", "", paste(NA))
# [1] ""
is.na(NA)
# [1] TRUE
is.na(paste(NA))
# [1] FALSE

抱歉搅了锅，但一些文件对此并不清楚。这可能归结为R解析器/deparser，以及您可以在R中将任何内容转换为文本字符对象的事实

---

原职：

但是，现在参考“一个

值将与另一个

值相匹配。”

如果

NA

不等于自身，为什么在

match

中与自身匹配？而且在

中也是相同的

？这是故意的吗

NA == NA  ## expecting TRUE
# [1] NA
NA != NA
# [1] NA
x <- NA
x == x
# [1] NA
match(NA, NA)
# [1] 1
identical(NA, NA)
# [1] TRUE
all.equal(NA, NA)
# [1] TRUE

NA==NA##应为TRUE
#[1]NA
不NA
#[1]NA
这是惯例问题。
=
的工作方式有很好的理由
NA
是R中的一个特殊值，应该表示缺失的数据，并且应该与其他数据区别对待。如果我们开始比较缺失的值，就好像它们是已知的，或者两个缺失的值相等，那么可能会出现无数非常微妙的错误

把
NA
想象成“我不知道那里有什么”。
3>NA
的正确答案显然是
NA
，因为我们不知道缺失值是否大于3。嗯，
NA==NA也一样。它们都是缺失值，但真实值可能大不相同，因此正确答案是“我不知道”

R不知道你在分析中做了什么，所以它不允许比较运算符认为NA是一个值，而不是潜在地引入错误，这些错误最终会被发布并让你感到尴尬

match（）。如果你问“我应该将3与NA匹配吗？”这个问题，一个合理的答案是“否”。不同的（而且非常有用）约定，并且是合理的，因为R几乎知道当你调用
match（）
时你要做什么。现在，我们是否应该为此目的将
NA
与
NA
匹配？这是有争议的

想想看，
match（）
的作者选择默认允许
NA
与自身匹配，这有点奇怪。您可以想象使用
match（）
查找
table
中的
NA
行以及其他值的情况，但这很危险。您只需要更加小心地了解x中是否有NA值，并且只在您真正想要的时候才允许它们。调用
match（）
时，可以通过指定
comparables=NA
来更改此行为
 添加@farnsy的伟大答案，并详细说明
=
和
匹配的区别：

要考虑的关键是如何使用这两个函数（<代码>＝< /代码>和<代码>匹配< /代码>）。
x == y
translation:  Is the value on the left the same value as the one on the right

match(x, table)
translation:  Is the value on the left found in the table on the right; 
              if so, return the index of the FIRST TIME that x appears in table

我经常遇到的一个常见用例是使用一组ID。特别是，在处理已连接的两个不同数据集时，我的一个ID列中可能会有几个NAs

但是，并非所有NAs都代表相同的现实对象
 我不太清楚你在问什么。您引用规范中描述您观察到的行为的部分，这似乎表明这是故意的；然后你问“这是故意的吗？”，好像你不确定。您有什么理由怀疑吗？您可能应该注意到，
idential（NA，NA\u integer）
返回false，所以这一部分并不令人惊讶。@joran，但这不是仅仅因为逻辑不匹配整数吗？…至于
match
，这似乎是在编写语言时发生的数百万至少部分主观的设计决策之一。唯一真正的答案可能是它对最初编写它的人来说是有意义的。
？idential
有一个参数
single.NA
，如果设置为
FALSE
将返回FALSE。它默认测试它们在概念上是否相等，而不是
=
。从
？==
，“NAs是不可比的，甚至连它们自己也不可比”。我猜，
匹配
也有概念上的接触，因为它提到：“在某种程度上，确切匹配的东西是一个定义问题。”但不知道
？所有。相等。它甚至没有提到
NA
AFAICT。我发现“match（）的作者选择默认允许NA与自身匹配”非常奇怪。在哪种违反直觉的情况下，您希望出现这种行为？它将是一个特定的用例，因此不应该是默认的。