Data.table: Keyby / by는 부분 집합으로 고유 한 그룹을 반환하지 않음

버그라고 동의합니다.

기록을 위해이 경우 권장되는 코드는 다음과 같습니다.

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