Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dplyr 'lag' does not respect its generic nature #277

Closed
njcray opened this issue Feb 21, 2014 · 3 comments
Closed

dplyr 'lag' does not respect its generic nature #277

njcray opened this issue Feb 21, 2014 · 3 comments
Assignees
Labels
bug an unexpected problem or unintended behavior
Milestone

Comments

@njcray
Copy link

njcray commented Feb 21, 2014

'lag' is a generic function in R. Some packages extend it - for example xts does this.

So this works:

library(xts)
x=xts(1:32,order.by=seq(from=as.Date("2014-01-01"),to=as.Date("2014-02-01"),by="days"))
x
lag(x,k=4)
lag(x,k=4,na.pad=FALSE)
lag(x,4)

But if we now attach the dplyr library it does not extend the lag generic function. It replaces it with an explicit function which breaks xts functionality.

library(dplyr)
lag(x,k=4)
# Error in lag(x, k = 4) : unused argument (k = 4)
lag(x,k=4,na.pad=FALSE)
# Error in lag(x, k = 4, na.pad = FALSE) : 
#  unused arguments (k = 4, na.pad = FALSE)
lag(x,4)
# [1] NA NA NA NA  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
# (loses xts attributes)
> sessionInfo()
R version 3.0.2 (2013-09-25)
Platform: x86_64-w64-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United Kingdom.1252  LC_CTYPE=English_United Kingdom.1252    LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C                            LC_TIME=English_United Kingdom.1252    

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

other attached packages:
[1] dplyr_0.1.1 xts_0.9-7   zoo_1.7-10 

loaded via a namespace (and not attached):
[1] assertthat_0.1  grid_3.0.2      lattice_0.20-24 Rcpp_0.11.0     tools_3.0.2    
@hadley hadley added the bug label Mar 17, 2014
@hadley hadley added this to the v0.2 milestone Mar 17, 2014
@hadley hadley self-assigned this Mar 17, 2014
@Fluxionist
Copy link

I am facing exactly the same issue. Though I can write xts::lag() explicitly in my own code, there are tons of other packages already using "lag()" and it is hard to avoid them. What is the necessity to mask the default behavior of stats::lag and filter instead of choosing some other names for those functions?

Even if you ignore xts users, there are still lots of codes using stats::lag(x, k=xxx) which cause an error when dplyr is loaded.

@bwlewis
Copy link

bwlewis commented Apr 1, 2014

I agree, and I think 'filter' is particularly inappropriate to use, since the available R 'Filter' function is a closer match to what dplyr is doing.

@hadley
Copy link
Member

hadley commented Apr 7, 2014

Agreed, I just haven't had the time to make the fix. Pull requests welcomed.

@hadley hadley modified the milestones: 0.3, v0.2 Apr 7, 2014
@hadley hadley closed this as completed in 742e416 Aug 28, 2014
krlmlr pushed a commit to krlmlr/dplyr that referenced this issue Mar 2, 2016
@lock lock bot locked as resolved and limited conversation to collaborators Jun 10, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

4 participants