我想这与那个故事有关:Changing behaviour of stats::lag when loading dplyr package ,但我发现了 lag
的一些奇怪行为当我尝试使用 default =
时的功能选项。
检查下面的简单命令
library(dplyr)
df = data.frame(mtcars)
df %>% mutate(lag_cyl = lag(cyl))
## it works with NA in first value (as expected)
df %>% mutate(lag_cyl = lag(cyl, default = 999))
## it works with a given value as default
df %>% mutate(lag_cyl = lag(cyl, default = cyl[1]))
## it DOESN'T WORK with the first value of the column as default
df %>% mutate(lag_cyl = dplyr::lag(cyl, default = cyl[1]))
## it works when specifying dplyr::
val = df$cyl[1]
df %>% mutate(lag_cyl = lag(cyl, default = val))
## it works when I assign the first value of the column to a variable name
难道只是
stats
之间的冲突吗?和 dplyr
包?
最佳答案
我可以确认df %>% mutate(lag_cyl = lag(cyl, default = cyl[1]))
适用于 dplyr 版本 0.8.0.1。
如果在指定 dplyr::lag
时有效它表明另一个库正在掩盖该功能。 Hmisc 有一个叫做lag 的函数,你可能在加载dplyr 之后加载了这个库(或者另一个有lag 函数的库)。
关于r - dplyr 内部 mutate 滞后函数的奇怪行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33522327/