Abaixo está um exemplo simples onde keyby (também por) não está retornando grupos únicos com subconjuntos.
No entanto, uma vez que o subconjunto é removido, o keyby funciona corretamente.
library(data.table)
# data.table 1.10.5 IN DEVELOPMENT built 2018-03-21 23:49:00 UTC; travis
# The fastest way to learn (by data.table authors): https://www.datacamp.com/courses/data-analysis-the-data-table-way
# Documentation: ?data.table, example(data.table) and browseVignettes("data.table")
# Release notes, videos and slides: http://r-datatable.com
# small dataset
dat <- data.table(Group = rep(c("All", "Not All"), times = 4), count = 1:8, ID = rep(1:2, each = 4))
# keyby returning non unique IDs with subset
dat[Group == "All" ,lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= c("count"), keyby = ID, verbose = TRUE]
# Creating new index 'Group'
# Creating index Group done in ... 0.001sec
# Optimized subsetting with index 'Group'
# on= matches existing index, using index
# Starting bmerge ...done in 0.000sec
# 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: 1 12
# keyby working fine without subset
dat[,lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= c("count"), keyby = 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) ...
# memcpy contiguous groups took 0.000s for 2 groups
# eval(j) took 0.000s for 2 calls
# 0.000sec
# ID count
# 1: 1 10
# 2: 2 26
sessionInfo()
R version 3.4.4 (2018-03-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 9 (stretch)
Matrix products: default
BLAS: /usr/lib/openblas-base/libblas.so.3
LAPACK: /usr/lib/libopenblasp-r0.2.19.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=C
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] data.table_1.10.5
loaded via a namespace (and not attached):
[1] compiler_3.4.4
Concordo que é um bug.
Para registro, o código recomendado neste caso é:
dat[Group == "All", lapply(.SD, sum, na.rm = TRUE), .SDcols= c("count"), keyby = ID]
O que dá a resposta correta, já que esta versão ativará GForce
e o bug não está presente nesse caso.
Claro que isso não ajuda se o seu código real não pode ser confundido assim.
Curiosamente, se passarmos as linhas do subconjunto diretamente, o código funcionará:
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
Vejo a seguinte diferença na saída de verbose
:
Subconjunto otimizado com índice 'Grupo'
Isso me levou a instalar do CRAN; o código é executado sem erros em 1.10.4-3
.
Então eu acho que isso é algo do trabalho de
Também vejo o mesmo erro se tornarmos a junção explícita:
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
Mas a versão codificada está bem:
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
Obrigado @cathine por relatar e a @MichaelChirico por investigar.
A causa raiz é o comportamento com erros da versão de junção, conforme apontado por Michael:
dat[.('All'), on = 'Group', lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= "count", keyby = ID]
Provavelmente serei resolvido quando o problema nº 2591 for resolvido.
Na nova otimização de subconjuntos, os subconjuntos são redirecionados para a parte de junção de data.table
, portanto, este bug agora afeta subconjuntos, bem como junções. Vou tentar investigar o mais rápido possível se posso resolver o problema.
Até então, você pode recorrer a
dat[Group == "All"][ ,lapply(.SD, function(x) sum(x, na.rm = TRUE)), .SDcols= c("count"), keyby = ID, verbose = TRUE]
por exemplo.
Desculpe pela inconveniência.
Obrigado @cathine! Confirmado que isso é apenas para desenvolvimento e pode ser aliviado com options(datatable.optimize=2)
pois o problema parece estar no nível 3 de otimização. Estou me perguntando como isso escapou dos testes!
Exemplos ainda mais simples de outro contato que também relatou:
> 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
>
Por que passou pelos testes? Porque só ocorre se a coluna de agrupamento for classificada (veja o código abaixo)! Não verifiquei especificamente o agrupamento em colunas classificadas.
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
Comentários muito úteis
Concordo que é um bug.
Para registro, o código recomendado neste caso é:
O que dá a resposta correta, já que esta versão ativará
GForce
e o bug não está presente nesse caso.Claro que isso não ajuda se o seu código real não pode ser confundido assim.
Curiosamente, se passarmos as linhas do subconjunto diretamente, o código funcionará:
Vejo a seguinte diferença na saída de
verbose
:Isso me levou a instalar do CRAN; o código é executado sem erros em
1.10.4-3
.Então eu acho que isso é algo do trabalho de
Também vejo o mesmo erro se tornarmos a junção explícita:
Mas a versão codificada está bem: