R中magrittr和arima的兼容性问题 [英] compatibility issue of magrittr and arima in R
问题描述
考虑以下示例:
library(tidyverse)
set.seed(1)
forecast::forecast
x <- cumsum(rnorm(10))
y1 <- arima(x, order = c(1, 0, 0))
y2 <- x %>% arima(order = c(1, 0, 0))
length(fitted(y1))
[1] 10
length(fitted(y2))
[1] 0
对象 y1 和 y2 几乎相同，唯一的例外是插槽 call 和 series .因此，我想这就是 fitted 函数开始发挥作用的地方.
The objects y1and y2are almost identical, the only exceptions being the slots calland series. So I guess that is where the fitted functions starts its magic.
我真的很想使用 y1 而不是 y2 .有人知道 fitted 的替代功能会产生相同的结果吗?
I would really like to work with y1 instead of y2.
Does anyone know an alternative function to fitted which produces the same result?
如果未将 forecast 包(例如通过 forecast :: forecast )加载到名称空间中，则不会出现上述错误".我不知道将程序包加载到名称空间会更改某些功能的行为.
The above "bug" does not appear if the forecast package is not loaded into namespace (via eg. forecast::forecast).
I wasnt aware that loading a package into namespace changes the behaviour of some functions.
由于代码似乎不可复制，因此我添加了`sessionInfo()´
since the code seems not to be reproducible I add my `sessionInfo()´
R version 3.5.2 (2018-12-20)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 7 x64 (build 7601) Service Pack 1
Matrix products: default
locale:
[1] LC_COLLATE=German_Austria.1252 LC_CTYPE=German_Austria.1252 LC_MONETARY=German_Austria.1252 LC_NUMERIC=C LC_TIME=German_Austria.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] forcats_0.4.0 stringr_1.3.1 dplyr_0.8.0.1 purrr_0.3.0 readr_1.3.1 tidyr_0.8.2 tibble_2.0.1 ggplot2_3.1.0 tidyverse_1.2.1 magrittr_1.5
loaded via a namespace (and not attached):
[1] zoo_1.8-4 tidyselect_0.2.5 urca_1.3-0 aTSA_3.1.2 haven_2.0.0 lattice_0.20-38 colorspace_1.4-0 generics_0.0.2 yaml_2.2.0 utf8_1.1.4 rlang_0.3.1 pillar_1.3.1
[13] withr_2.1.2 glue_1.3.0 forecast_8.5 TTR_0.23-4 modelr_0.1.2 readxl_1.2.0 plyr_1.8.4 quantmod_0.4-13 timeDate_3043.102 munsell_0.5.0 gtable_0.2.0 cellranger_1.1.0
[25] rvest_0.3.2 tseries_0.10-46 lmtest_0.9-36 parallel_3.5.2 curl_3.3 fansi_0.4.0 broom_0.5.1 xts_0.11-2 Rcpp_1.0.0 scales_1.0.0 backports_1.1.3 jsonlite_1.6
[37] fracdiff_1.4-2 hms_0.4.2 stringi_1.3.1 grid_3.5.2 cli_1.0.1 quadprog_1.5-5 tools_3.5.2 lazyeval_0.2.1 crayon_1.3.4 pkgconfig_2.0.2 xml2_1.2.0 lubridate_1.7.4
推荐答案
What you've identified is a problem caused by non-standard evaluation, which is briefly mentioned in the technical note about the magrittr pipe:
magrittr管操作员使用非标准评估.他们捕获他们的输入，并检查他们以找出继续进行的方法.第一个功能是从各个右侧产生的表达式，然后通过应用此函数获得结果到左侧在大多数情况下，您可以忽略细微之处magrittr评估的各个方面，但某些功能可能会捕获它们的功能调用环境，因此使用运算符将不完全是相当于没有管道操作员的标准呼叫".
The magrittr pipe operators use non-standard evaluation. They capture their inputs and examines them to figure out how to proceed. First a function is produced from all of the individual right-hand side expressions, and then the result is obtained by applying this function to the left-hand side. For most purposes, one can disregard the subtle aspects of magrittr's evaluation, but some functions may capture their calling environment, and thus using the operators will not be exactly equivalent to the "standard call" without pipe-operators.
如果查看 fitted 的 arima 版本的源代码，您会发现您认为 call 属性是必不可少的，这是正确的该方法的操作:
If you look at the source for arima version of fitted you can see that you were correct in thinking that the call attribute is essential to the method's operation:
getAnywhere(fitted.Arima)
A single object matching ‘fitted.Arima’ was found
It was found in the following places
registered S3 method for fitted from namespace TSA
namespace:TSA
with value
function (object, ...)
{
fitted = eval(object$call$x) - object$residuals
fitted
}
<bytecode: 0x000000001e8ff4d8>
<environment: namespace:TSA>
这篇关于R中magrittr和arima的兼容性问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
