【问题标题】:Why NaN/NA is NaN?为什么 NaN/NA 是 NaN?
【发布时间】:2022-02-10 11:16:50
【问题描述】:
R> 1/NA
[1] NA
R> NaN/NA
[1] NaN

一个数除以 NA 就是 NA。 NaN 甚至不是一个数字。所以定义NaN除以NA为NA更为合理。

我不明白将其定义为 NaN 的逻辑。是R的精心设计选择吗?或者只是在 R 或 S 诞生时卡住的一个偶然的选择。

我不需要任何猜测的答案来回答这个问题。需要经过深思熟虑的R原设计者给出权威答案。

【问题讨论】:

  • 我的意思是答案应该是权威的。它可以由 R 的原始设计者回答,但在其他一些地方。基于该原始来源在 SO 上发布的答案是可以的。 MikeJagan 目前的回答不能令人满意地回答我的问题。它只是解释了它不是为什么会这样。如果没有确定此功能的 R 的原始设计者的意见,我认为无法令人满意地回答此答案。

标签: r


【解决方案1】:

您可以查阅由 R 的维护人员编写的文档。来自?NaN

涉及NaN 的计算将返回NaNNA:不能保证这两者中的哪一个,可能取决于R 平台(因为编译器可能会重新排序计算)。

在我的机器上,以下返回NA_real_不是NaN

NaN / NA
NA / NaN

NaN / NA_integer_
NA_integer_ / NaN

NaN / NA_real_
NA_real_ / NaN

内部结构、性能等

在 C 级别,NaNNA_real_ 是 IEEE 754 NaNs 的两种类型,仅通过 double 的有效位字段中的位进行区分。同时NANA_integer_都是INT_MIN

为确保涉及NaN 的算术在平台之间产生一致的结果,R 需要对z = a <op> b每个 操作执行以下操作:

  • 检查z是否为NaN
    • 如果是,请检查z 是否是所需类型的NaN
      • 如果不是,请将z 设置为等于所需类型的NaN

这些检查会产生不可接受的性能成本。

归根结底,当前的行为是一种妥协,更注重速度而不是一致性。由用户和包开发人员决定一致性是否足够重要以证明这样做是合理的:

z <- a + b
z[is.nan(z)] <- NA

考虑到大多数用户很少遇到NaN,而且大多数软件包都不会尝试将其与NA_real_ 区分开来,我会说这种设计很有意义。

参考文献

FWIW,这里有四个相关的线程:

  • NA_real_ NaN -> NA 或 NaN,我们应该关心吗?,R-devel,2009 年 4 月 [1] [2]
  • 问题:NA,R 中的 NaN,R-devel,2014 年 2 月 [3]
  • 1954 年来自北美,R-devel,2021 年 5 月 [4]
  • NA_real_ 和 NaN 之间的差异,Stack Overflow,2021 年 12 月 [5]

前三名收到了来自 R Core 团队成员的数个 cmets。一般来说,R-devel 是解决这类问题的更好论坛...

【讨论】:

  • 请注意,NA/NaNNANaN/NANaN,因此传递给 R 解析器进行二进制算术运算的参数的顺序似乎决定了结果。
  • 这并不能解释为什么 NaN/NA 应该返回 NaN。我认为 R 可以被制作成无论底层架构是什么,它总是 NA 。我认为返回 NaN 没有意义。此外,使结果依赖于架构是一个糟糕的设计选择。
  • 在 C 级别检查 NaN 类型会显着减慢基本算术运算。
猜你喜欢
  • 2013-12-17
  • 2013-11-26
  • 2020-03-12
  • 2019-01-01
  • 2019-11-13
  • 1970-01-01
  • 2017-05-10
相关资源
最近更新 更多