arrange_at(vars(...)) chokes if a variable is used for grouping, arrange(...) does not

[mlell]

The function arrange_at(.) throws an 'object not found' error if a variable is used for sorting which is set as grouping variable.

Examples which work:

mtcars %>% arrange(cyl)
## [Sorted output of mtcars]

# Same meaning, using arrange_at
mtcars %>% group_by(cyl) %>% arrange_at(vars(cyl))
## [Sorted output of mtcars]

However, if the data frame is grouped, only the first version works:

mtcars %>% group_by(cyl) %>% arrange(cyl)
## [Sorted output of mtcars]
# Same meaning,  but does not work:
mtcars %>% group_by(cyl) %>% arrange_at(vars(cyl))
## Error in overscope_eval_next(overscope, expr) : object 'cyl' not found

If a grouped data frame is returned to non-grouped state, both approaches work again:

mtcars %>% group_by(cyl) %>% group_by() %>% arrange_at(vars(-cyl))
## [Sorted output of mtcars]

This is confusing if I want, for example, sort a wide data table containing one name column and many data dimensions by all columns except the name. I need to use

widedata %>% arrange_at(vars(-NameColumn))

If widedata is a result of a prior operation involving grouping, I must explicitly remove the grouping. This would be OK, if technically needed but I think at least the error message

Error in overscope_eval_next(overscope, expr) : object '.....' not found

should be replaced by something like

Error: cannot arrange_by by a column used for grouping

Or, if technically feasible, of course it would be more awesome if arrange_at did not care about grouping!

> sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS: /opt/Bio/R/3.4.3/lib64/R/lib/libRblas.so
LAPACK: /opt/Bio/R/3.4.3/lib64/R/lib/libRlapack.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=en_US.UTF-8
 [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] bindrcpp_0.2 dplyr_0.7.4

loaded via a namespace (and not attached):
 [1] compiler_3.4.3   magrittr_1.5     assertthat_0.2.0 R6_2.2.2
 [5] cli_1.0.0        pillar_1.1.0     glue_1.2.0       tibble_1.4.1
 [9] crayon_1.3.4     Rcpp_0.12.15     utf8_1.1.3       pkgconfig_2.0.1
[13] rlang_0.1.6      bindr_0.1

[krlmlr]

Thanks, confirmed:

suppressPackageStartupMessages(library(dplyr))
mtcars %>% group_by(cyl) %>% arrange_at(vars(cyl))
#> Error in FUN(X[[i]], ...): object 'cyl' not found

Created on 2018-02-01 by the reprex package (v0.1.1.9000).

Did this work with dplyr 0.5.0?

[mlell]

Err... no, but for the reason that arrange_at seemingly hadn't existed yet in dplyr 0.5.0...

> sessionInfo()
## R version 3.4.3 (2017-11-30)
## Platform: x86_64-pc-linux-gnu (64-bit)
## Running under: Arch Linux
## 
## Matrix products: default
## BLAS: /usr/lib/libblas.so.3.8.0
## LAPACK: /usr/lib/liblapack.so.3.8.0
## 
## locale:
##  [1] LC_CTYPE=de_DE.utf8       LC_NUMERIC=C             
##  [3] LC_TIME=de_DE.utf8        LC_COLLATE=de_DE.utf8    
##  [5] LC_MONETARY=de_DE.utf8    LC_MESSAGES=de_DE.utf8   
##  [7] LC_PAPER=de_DE.utf8       LC_NAME=C                
##  [9]LC_ADDRESS=C              LC_TELEPHONE=C           
## [11] LC_MEASUREMENT=de_DE.utf8 LC_IDENTIFICATION=C      
## 
## attached base packages:
## [1] stats     graphics  grDevices utils     datasets  methods   base     
## 
## other attached packages:
## [1] dplyr_0.5.0
## 
## loaded via a namespace (and not attached):
## [1] compiler_3.4.3 magrittr_1.5   R6_2.2.0       assertthat_0.1 tools_3.4.3   
## [6] DBI_0.6        tibble_1.2     Rcpp_0.12.9   
## 

mtcars %>% group_by(cyl) %>% arrange_at(vars(cyl))
## Fehler in arrange_at(., vars(cyl)) : 
##   konnte Funktion "arrange_at" nicht finden

[krlmlr]

Thanks. We seriously need an "Available since" entry somewhere, perhaps created by roxygen2?

What about 0.7.0?

[krlmlr]

@romainfrancois: Are you by any chance looking into this problem now?

[romainfrancois]

yes, this is related to #3351

[krlmlr]

Closing in favor of #3351. @romainfrancois: Can you please double-check if #3351 covers everything raised here?

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/