数据滞后项怎么算？

suimong 发表于 2015-12-16 01:44
你的理解没错，lag(ldeaths, k=1)的变动方向确实和你想要的是反了。但这是因为stats::lag的本质不是lag，是 ...

我昨天在 stackoverflow 发帖询问，也得到了权威的回答，结果的确是像你所说，lagX 是 X[t+1] , 我也想起来 plm 包的作者在对 plm 讲解的文件里说过系统默认的 lag 和 diff 不是字面理解， 终于明白是怎么回事了。

suimong 发表于 2015-12-16 01:44
你的理解没错，lag(ldeaths, k=1)的变动方向确实和你想要的是反了。但这是因为stats::lag的本质不是lag，是 ...

我在 stackoverflow 得到的回复说： dplyr 包是 inconsistent ,因此最好避免使用，我贴出来：

蓝色 发表于 2015-12-15 21:36
用
library(dplyr)
吧

fisk_all_star 发表于 2015-12-16 14:14
我在 stackoverflow 得到的回复说： dplyr 包是 inconsistent ,因此最好避免使用，我贴出来：

Grothendieck说的inconsistent意思是dplyr里的lag（还有lag.xts)的实现思路和R core里的lag不一样，也就是我说的方向问题，函数本身并没有问题。事实上Grothendieck本人对Hadley Wickham “擅自” override stats::lag非常不满意以至于在github上直接开了一个issue，但是被Hadley给一口回绝了，见这里。Grothendieck对于inconsistency的担忧其实更多的还是出于向后兼容的考虑。因此到底用哪个完全取决于你更习惯哪种lag的思维方式，inconsistency对大部分人来说不是问题。
有些人会偏向于使用尽量和R core兼容的包和实现，然而我个人经验是R core里inconsistent的地方也很多，而高质量的包会在内部做到consistent并且好用（Hadley Wickham的各个包就很强调consistency），那我更倾向于使用非R core的方法。一点个人经验供你参考。

suimong 发表于 2015-12-16 01:44
你的理解没错，lag(ldeaths, k=1)的变动方向确实和你想要的是反了。但这是因为stats::lag的本质不是lag，是 ...

受教了~

fisk_all_star 发表于 2015-12-15 20:58
我按照你的试了一遍，结果显示这个：
> data
  year x lagx

我用stats后，也没有滞后，想问楼主最后怎么解决的