R的data.table截断位？

Question

所以我是一个巨大的data.table R 中的粉丝。我几乎一直都在使用它，但遇到了一种情况，它根本不适合我。我有一个使用 R 的 double 的包(我公司内部的)存储一个无符号 64 位整数的值，其位序列对应于某种奇特的编码。这个包在除 data.table 之外的任何地方都能很好地工作。我发现，如果我对这些数据的一列进行聚合，我会丢失大量的唯一值。我唯一的猜测是 data.table正在以某种奇怪的方式截断位 double优化。

任何人都可以确认是这种情况吗？这只是一个错误吗？

下面是这个问题的重现，并与我目前必须使用但想要避免使用的包进行比较 (dplyr)。

temp <- structure(list(obscure_math = c(6.95476896592629e-309, 6.95476863436446e-309, 
6.95476743245288e-309, 6.95476942182375e-309, 6.95477149408563e-309, 
6.95477132830476e-309, 6.95477132830476e-309, 6.95477149408562e-309, 
6.95477174275702e-309, 6.95476880014538e-309, 6.95476896592647e-309, 
6.95476896592647e-309, 6.95476900737172e-309, 6.95476900737172e-309, 
6.95476946326899e-309, 6.95476958760468e-309, 6.95476958760468e-309, 
6.95477020928318e-309, 6.95477124541406e-309, 6.95476859291965e-309, 
6.95476875870014e-309, 6.95476904881676e-309, 6.95476904881676e-309, 
6.95476904881676e-309, 6.95476909026199e-309, 6.95476909026199e-309, 
6.95476909026199e-309, 6.95476909026199e-309, 6.9547691317072e-309, 
6.9547691317072e-309, 6.9547691317072e-309, 6.9547691317072e-309, 
6.9547691317072e-309, 6.9547691317072e-309, 6.9547691317072e-309, 
6.9547691317072e-309, 6.9547691317072e-309, 6.9547691317072e-309, 
6.9547691317072e-309, 6.9547691317072e-309, 6.95477211576406e-309, 
6.95476880014538e-309, 6.95476880014538e-309, 6.95476880014538e-309, 
6.95476892448104e-309, 6.95476880014538e-309, 6.95476892448105e-309, 
6.9547689659263e-309, 6.95476913170719e-309, 6.95476933893334e-309
)), .Names = "obscure_math", class = c("data.table", "data.frame"), row.names = c(NA, 
-50L))

dt_collapsed <- temp[, .(count=.N), by=obscure_math]
nrow(dt_collapsed) == length(unique(temp$obscure_math))

setDF(temp)
dplyr_collapsed <- temp %>% group_by(obscure_math) %>% summarise(count=n())
nrow(dplyr_collapsed) == length(unique(temp$obscure_math))

Answer 1

更新: current development version of data.table (v1.9.7) 中删除了默认的舍入功能。 .开发版本见安装说明here .

这也意味着您有责任了解表示浮点数和处理它的限制。

data.table 已经存在了很长时间。我们过去常常通过使用阈值来处理浮点表示的限制(就像基础 R 所做的那样，例如 all.equal )。然而，它根本不起作用，因为它需要根据比较的数字有多大进行自适应。 This series of articles是关于这个主题和其他潜在问题的优秀读物。

这是一个反复出现的问题，因为 a) 人们没有意识到限制，或者 b) 阈值并没有真正帮助他们解决问题，这意味着人们一直在这里提问或在项目页面上发帖。

虽然我们将 data.table 的顺序重新实现为快速基数排序，但我们借此机会提供了另一种解决问题的方法，并在证明不受欢迎时提供了一种解决方法(导出 setNumericRounding)。对于 #1642 问题，排序可能不需要对 double 数进行舍入(但这并不是那么简单，因为顺序直接影响基于二进制搜索的子集)。

这里的实际问题是对浮点数进行分组，更糟糕的是像你这样的数字。恕我直言，这只是一个糟糕的选择。

我可以想到两种前进的方式:

当对实际上是 double 的列进行分组时(在 R 中，1 是 double 而不是 1L，并且这些情况没有问题)，我们提供一个警告，最后 2 个字节被四舍五入，人们应该阅读 ?setNumericRounding .并且还建议使用bit64::integer64 .

删除允许对真正的 double 值进行分组操作的功能，或强制它们在继续之前将精度固定为某些数字。我想不出一个真正想要按浮点数分组的正当理由(很想听听这样做的人的意见)。

不太可能发生的是回到基于阈值的检查来识别哪些 double 应该属于同一组。

为了让 Q 保持回答，请使用 setNumericRounding(0L) .