2015-01-30 13 views
21

Voglio trovare l'elemento lead() e lag() in ogni gruppo, ma ho avuto risultati errati.dplyr: lead() e lag() errati se usati con group_by()

Ad esempio, i dati è come questo:

library(dplyr) 
df = data.frame(name=rep(c('Al','Jen'),3), 
       score=rep(c(100, 80, 60),2)) 
df 

dati:

name score 
1 Al 100 
2 Jen 80 
3 Al 60 
4 Jen 100 
5 Al 80 
6 Jen 60 

Ora cerco di scoprire piombo() e lag() realizza per ogni persona. Se io a ordinare utilizzando organizzare(), posso ottenere la risposta corretta:

df %>% 
    arrange(name) %>% 
    group_by(name) %>% 
    mutate(next.score = lead(score), 
     before.score = lag(score)) 

OUTPUT1:

Source: local data frame [6 x 4] 
Groups: name 

     name score next.score before.score 
    1 Al 100   60   NA 
    2 Al 60   80   100 
    3 Al 80   NA   60 
    4 Jen 80  100   NA 
    5 Jen 100   60   80 
    6 Jen 60   NA   100 

Senza organizzare(), il risultato è sbagliato:

df %>% 
    group_by(name) %>% 
    mutate(next.score = lead(score), 
     before.score = lag(score)) 

OUTPUT2:

Source: local data frame [6 x 4] 
Groups: name 

    name score next.score before.score 
1 Al 100   80   NA 
2 Jen 80   60   NA 
3 Al 60  100   80 
4 Jen 100   80   60 
5 Al 80   NA   100 
6 Jen 60   NA   80 

Ad esempio, in prima linea, il prossimo album di Al dovrebbe essere 60 (terza linea).

Qualcuno sa perché questo è successo? Perché arrangement() influisce sul risultato (i valori, non solo sull'ordine)? Grazie ~

+0

@DavidArenburg non è l'ordinamento, l'OP chiede perché il risultato è 80 quando nel frame di dati originale il risultato successivo è 60. È come se il risultato di Jen fosse selezionato al posto di Al's –

+0

E non riesco a ripeterlo. Quale versione di R stai usando? Ottengo '1 Al 100 60 NA' con R 3.1.2 su Windows 7 –

+0

@PanagiotisKanavos, sì hai ragione. Non me ne sono accorto. –

risposta

23

Sembra che tu debba passare argomenti addizionali alle funzioni lag e lead. Quando eseguo la tua funzione senza organizzare, ma con order_by aggiunto, tutto sembra essere ok.

df %>% 
group_by(name) %>% 
mutate(next.score = lead(score, order_by=name), 
before.score = lag(score, order_by=name)) 

uscita:

name score next.score before.score 
1 Al 100   60   NA 
2 Jen 80  100   NA 
3 Al 60   80   100 
4 Jen 100   60   80 
5 Al 80   NA   60 
6 Jen 60   NA   100 

mio sessionInfo():

R version 3.1.1 (2014-07-10) 
Platform: x86_64-w64-mingw32/x64 (64-bit) 

locale: 
[1] LC_COLLATE=Polish_Poland.1250 LC_CTYPE=Polish_Poland.1250  LC_MONETARY=Polish_Poland.1250 
[4] LC_NUMERIC=C     LC_TIME=Polish_Poland.1250  

attached base packages: 
[1] stats  graphics grDevices utils  datasets methods base  

other attached packages: 
[1] dplyr_0.4.1 

loaded via a namespace (and not attached): 
[1] assertthat_0.1 DBI_0.3.1  lazyeval_0.1.10 magrittr_1.5    parallel_3.1.1 Rcpp_0.11.5  
[7] tools_3.1.1 
+0

Sto lavorando con un caso simile di lag, ma con una modifica: più colonne per raggruppare e ordinare! Se ci fossero più colonne in group_by e order_by, quanto sarà diversa la risposta? Ho provato a passare i vettori ma questo non aiuta. –

1

Utilizzando order_by è buono quando si dispone di una sola variabile di raggruppamento. In caso di più variabili di raggruppamento, non sono riuscito a trovare alcuna soluzione tranne che scrivere e leggere la tabella per sbarazzarsi delle variabili di raggruppamento. Ha funzionato abbastanza bene per me, ma la sua efficienza dipende dalle dimensioni del tavolo.

+0

Ho creato una variabile di raggruppamento fittizio per questo caso per consentire l'utilizzo di order_by: 'mutate (grouping = sprintf ("% 04d-% 04d ", var1, var2))%>% mutate (next.score = lead (punteggio, order_by = raggruppamento)%>% seleziona (-gruppo) ' – Quantum7

Problemi correlati