为什么DataFrames.jl实现NA而不是使用NaN？

DataFrames.jl为缺少的值执行

NA

：

help?> NA

NA

A value denoting missingness within the domain of any type.

然而，Julia已经有了NaN类型：

help?> NaN

NaN

A not-a-number value of type Float64.

---

这个设计决定的原因是什么？

所有编程语言都回答：

NA

表示缺少值

NaN

表示定义不明确的算术计算

根据定义，它们是不同的，因此需要两种不同的“事物”来描述它们

例如，考虑序列<代码> N/N < /代码> <代码> n=…，- 2，- 1, 0, 1，2，…< /代码>。在该序列中，当

n=0

时，序列元素为

0/0

，定义不明确，因此计算结果为

NaN

。但是序列

0/0

的元素在任何意义上都不会丢失，因此

NA

在这种情况下是不合适的

对比的例子是一些环境传感器的观测序列，

a、b、NA、d

。传感器在第三次观察中出现故障，因此记录为丢失。尽管如此，在第三次观察时，存在一些真实值

c

，如果传感器没有出现故障，则应记录该值，并且该值在算术上定义良好

在同一个数据集中发生这两件“事情”所需要的只是一些设置，其中可能会出现丢失的数据，以及在某些情况下可能无法很好地定义的观测值。紧接着，

NaN

和

NA

需要区分

---

朱莉娅特定答案：

NaN

属于

Float64

类型。但是，如果您的数据集属于其他类型，如

Int

或

String

，该怎么办？如果我们使用

NaN

表示缺少的数据，那么您的数据集需要是一个联合类型数组，例如

union{Int，Float64}

，或者

union{String，Float64}

，这意味着性能将受到影响（请参阅官方文档中讨论联合类型的性能提示部分）。相反，为了确保

NA

可以用于表示多种不同类型数组中的缺失数据，而不会造成太大的性能损失，已经做了大量的工作（从内存开始，最终达到v0.6）。这是如何实现的？这绝对是一个不同（但有趣）的问题，老实说，我认为我没有资格回答这个问题。

两条评论补充了答案：1）Julia离开了NA-相反，新的缺失值称为

缺失

，它明确表示缺失值。当前的想法是，一些不同的东西，例如

无效

或只是好的旧

无

应该表示未定义的计算结果（上面称之为NaN）

NaN

，它明确地是IEEE标准的一部分，将保留在该语言中。