Data.table: キーバイ/サブセット化された一意のグループを返さない

バグだということに同意します。

ちなみに、この場合の推奨コードは次のとおりです。

dat[Group == "All", lapply(.SD, sum, na.rm = TRUE), .SDcols= c("count"), keyby = ID]

このバージョンはGForceをアクティブにし、その場合はバグが存在しないため、これは正解です。

もちろん、実際のコードをこのように分類できない場合、これは役に立ちません。

興味深いことに、サブセット行を直接渡すと、コードは機能します。

dat[c(1, 3, 5, 7),
    lapply(.SD, function(x) sum(x, na.rm = TRUE)),
    .SDcols= "count", keyby = ID, verbose = TRUE]
# i clause present and columns used in by detected, only these subset: ID 
# Finding groups using forderv ... 0.000sec 
# Finding group sizes from the positions (can be avoided to save RAM) ... 0.000sec 
# lapply optimization changed j from 'lapply(.SD, function(x) sum(x, na.rm = TRUE))' to 'list(..FUN1(count))'
# GForce is on, left j unchanged
# Old mean optimization is on, left j unchanged.
# Making each group and running j (GForce FALSE) ... 
#   collecting discontiguous groups took 0.000s for 2 groups
#   eval(j) took 0.000s for 2 calls
# 0.000sec 
#    ID count
# 1:  1     4
# 2:  2    12

verbose出力に次の違いがあります。

インデックス「グループ」で最適化されたサブセット

これにより、CRANからインストールすることになりました。 コードは1.10.4-3エラーなしで実行されます。

だから私はこれがサブセット最適化に関する@MarkusBonschの仕事からのものだと思いますか？

結合を明示的にすると、同じエラーが表示されます。

dat[.('All'), on = 'Group',
    lapply(.SD, function(x) sum(x, na.rm = TRUE)),
    .SDcols= "count", keyby = ID]
#    ID count
# 1:  1     4
# 2:  1    12

ただし、キー付きバージョンは問題ありません。

setkey(dat, Group)
dat[.('All'), 
    lapply(.SD, function(x) sum(x, na.rm = TRUE)),
    .SDcols= "count", keyby = ID]#    ID count
# 1:  1     4
# 2:  2    12

報告してくれた@cathineと調査してくれた@MichaelChiricoに感謝します。
根本的な原因は、Michaelが指摘した結合バージョンのバグのある動作です。
dat[.('All'), on = 'Group', lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= "count", keyby = ID]

この問題＃2591が解決されると、おそらく解決されるでしょう。
新しいサブセットの最適化では、サブセットはdata.tableの結合部分にリダイレクトされるため、このバグは結合だけでなくサブセットにも影響するようになりました。 問題を解決できる場合は、できるだけ早く調査を試みます。
それまでは、
たとえば、 dat[Group == "All"][ ,lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= c("count"), keyby = ID, verbose = TRUE] 。
ご不便おかけしてすみません。

ありがとう@cathine！ これは開発専用であり、問​​題はレベル3の最適化にあると思われるため、 options(datatable.optimize=2)で軽減できることを確認しました。 これがどうやってテストをすり抜けたのだろうか！
報告した別の連絡先からのさらに簡単な例：

> DT = data.table(
    id = c("a","a","a","b","b","c","c","d","d"),
    group = c(1,1,1,1,1,2,2,2,2),
    num = 1)
> DT[, uniqueN(id), by=group]          # ok 
   group    V1
   <num> <int>
1:     1     2
2:     2     2
> DT[num==1, uniqueN(id), by=group]    # group column wrong
   group    V1
   <num> <int>
1:     1     2
2:     1     2
> options(datatable.optimize=2)
> DT[num==1, uniqueN(id), by=group]    # ok
   group    V1
   <num> <int>
1:     1     2
2:     2     2
> options(datatable.optimize=3)        # not ok
> DT[num==1, uniqueN(id), by=group]
   group    V1
   <num> <int>
1:     1     2
2:     1     2
> DT[num==1, sum(num), by=group]       # ok
   group    V1
   <num> <num>
1:     1     7
2:     2     4
> DT[num==1, length(num), by=group]    # not ok
   group    V1
   <num> <int>
1:     1     7
2:     1     4
> options(datatable.optimize=2)        # ok
> DT[num==1, length(num), by=group]
   group    V1
   <num> <int>
1:     1     7
2:     2     4
> 

なぜそれはテストをすり抜けたのですか？ これは、グループ化列がソートされている場合にのみ発生するためです（以下のコードを参照）。 ソートされた列のグループ化は特にチェックしませんでした。

library(data.table)
DT = data.table(
  id = c("a","a","a","b","b","c","c","d","d"),
  group = c(1,1,1,1,1,2,2,2,2),
  group2 = c(1,1,1,1,1,2,2,2,1),
  num = 1)
DT[, uniqueN(id), by=group]          # ok 
# group    V1
# <num> <int>
# 1:     1     2
# 2:     2     2
DT[num==1, uniqueN(id), by=group]    # group column wrong
# group    V1
# <num> <int>
# 1:     1     2
# 2:     1     2
DT[num==1, uniqueN(id), by=group2]    # ok with other group column that is not sorted
# group2 V1
# 1:      1  3
# 2:      2  2

setkey(DT, group2)
DT[num==1, uniqueN(id), by=group2]    # not ok anymore since the group column is sorted now
# group2 V1
# 1:      1  3
# 2:      1  2