r - data.table 中的大整数。 1.9.2 中的分组结果与 1.8.10 中的分组结果不同

Question

我最近将 data.table 从 1.8.10 升级到 1.9.2，在对大整数进行分组时，我发现两个版本之间存在以下差异。

是否需要在 1.9.2 中更改某个设置，以使以下两个组语句中的第一个像在 1.8.10 中一样工作(我认为 1.8.10 是正确的行为)？

此外，对于以下两组语句中的第二个语句，两个包中的结果是相同的，但这种行为是预期的吗？

10.8.1

>   library(data.table)
data.table 1.8.10  For help type: help("data.table")
>   foo = data.table(i = c(2884199399609098249, 2884199399608934409))
>   lapply(foo, class)
$i
[1] "numeric"

>   foo
                     i
1: 2884199399609098240
2: 2884199399608934400
>   foo[, .N, by=i]
                     i N
1: 2884199399609098240 1
2: 2884199399608934400 1
>   foo = data.table(i = c(9999999999999999999, 9999999999999999998))
>   foo[, .N, by=i]
                      i N
1: 10000000000000000000 2
> 

和1.9.2

>   library(data.table)
data.table 1.9.2  For help type: help("data.table")
>   foo = data.table(i = c(2884199399609098249, 2884199399608934409))
>   lapply(foo, class)
$i
[1] "numeric"

>   foo
                     i
1: 2884199399609098240
2: 2884199399608934400
>   foo[, .N, by=i]
                     i N
1: 2884199399609098240 2
>   foo = data.table(i = c(9999999999999999999, 9999999999999999998))
>   foo[, .N, by=i]
                      i N
1: 10000000000000000000 2
> 

用于第一次测试的数字(显示 data.table 版本之间的差异)是来 self 的实际数据集的数字，以及导致我的一些回归测试在升级 data.table 后失败的数字。

我很好奇第二个测试，在我将数字增加另一个数量级之后，是否期望在 data.table 包的两个版本中忽略最后一个有效数字的微小差异。

我假设这一切都与浮点表示有关。也许我处理这个问题的正确方法是将这些大整数表示为整数64或字符？我对是否要使用 integer64 感到犹豫，因为我不确定 data.table 和 R 环境是否完全支持它们，例如，我必须在之前的 data.table 代码中添加此内容:

options(datatable.integer64="character") # Until integer64 setkey is implemented

也许这已经实现了，但无论更改该设置，至少在我的环境中都不会改变这些测试的结果。我认为这是有道理的，因为这些值以数字形式存储在 foo 数据表中。

Answer 1

是的，v1.8.10 中的结果是正确的行为。我们在 v1.9.2 中改进了舍入方法。最好的解释在这里:

Grouping very small numbers (e.g. 1e-28) and 0.0 in data.table v1.8.10 vs v1.9.2

这意味着我们在支持存储在numeric类型中的大于2^31的整数方面出现了倒退。这个问题现已在 v1.9.3 中解决(可从 R-Forge 获取)，请参阅 NEWS :

o bit64::integer64 now works in grouping and joins, #5369. Thanks to James Sams for highlighting UPCs and Clayton Stanley.
Reminder: fread() has been able to detect and read integer64 for a while.

o New function setNumericRounding() may be used to reduce to 1 byte or 0 byte rounding when joining to or grouping columns of type numeric, #5369. See example in ?setNumericRounding and NEWS item from v1.9.2. getNumericRounding() returns the current setting.

因此，您可以调用 setNumericRounding(0) 来关闭所有 numeric 列的全局舍入，或者更好的是，为该列使用更合适的类型:bit64::integer64 现在已受支持。

v1.9.2 中的更改是:

o Numeric data is still joined and grouped within tolerance as before but instead of tolerance being sqrt(.Machine$double.eps) == 1.490116e-08 (the same as base::all.equal's default) the significand is now rounded to the last 2 bytes, apx 11 s.f. This is more appropriate for large (1.23e20) and small (1.23e-20) numerics and is faster via a simple bit twiddle. A few functions provided a 'tolerance' argument but this wasn't being passed through so has been removed. We aim to add a global option (e.g. 2, 1 or 0 byte rounding) in a future release [DONE].

?setNumericRounding 中的示例是:

> DT = data.table(a=seq(0,1,by=0.2),b=1:2, key="a")
> DT
     a b
1: 0.0 1
2: 0.2 2
3: 0.4 1
4: 0.6 2
5: 0.8 1
6: 1.0 2
> setNumericRounding(0)   # turn off rounding; i.e. if we didn't round
> DT[.(0.4)]   # works
     a b
1: 0.4 1
> DT[.(0.6)]   # no match!, confusing to users
     a  b      # 0.6 is clearing there in DT, and 0.4 worked ok!
1: 0.6 NA
>     
> setNumericRounding(2)   # restore default
> DT[.(0.6)]   # now works as user expects
     a b
1: 0.6 2
>     
> # using type 'numeric' for integers > 2^31 (typically ids)
> DT = data.table(id = c(1234567890123, 1234567890124, 1234567890125), val=1:3)
> DT[,.N,by=id]   # 1 row (the last digit has been rounded)
             id N
1: 1.234568e+12 3
> setNumericRounding(0)  # turn off rounding
> DT[,.N,by=id]   # 3 rows (the last digit wasn't rounded)
             id N
1: 1.234568e+12 1
2: 1.234568e+12 1
3: 1.234568e+12 1
>  # but, better to use bit64::integer64 for such ids instead of numeric
>  setNumericRounding(2)  # restore default, preferred