2015-05-26 11 views
17

Mam problem z funkcją stats::lag podczas korzystania z pakietu dplyr. Konkretnie, otrzymuję różne wyniki z funkcji opóźnienia przed i po załadowaniu dplyr.Zmiana zachowania statystyk :: opóźnienie podczas ładowania pakietu dplyr

Na przykład tutaj jest przykładowa seria czasowa. Gdybym obliczyć opóźnienie z k = -1, opóźnione serii rozpoczyna się w 1971 roku

data <- ts(1:10, start = 1970, frequency = 1) 
lag1 <- stats::lag(data, k = -1) 
start(lag1)[1] 

## [1] 1971 

Teraz, jeśli załadować dplyr, to samo wezwanie daje opóźniony cykl rozpoczynający się 1970.

library(dplyr) 

## 
## Attaching package: 'dplyr' 
## 
## The following object is masked from 'package:stats': 
## 
##  filter 
## 
## The following objects are masked from 'package:base': 
## 
##  intersect, setdiff, setequal, union 

lag2 <- stats::lag(data, k = -1) 
start(lag2)[1] 

## [1] 1970 

start(lag1)[1] == start(lag2)[1] 

## [1] FALSE 

Given ostrzeżenia przy ładowaniu dplyr, domyślam się, że to musi zrobić z Environments. Ale odłączenie dplyr wydaje się nie pomagać.

detach("package:dplyr", unload = TRUE, character.only = TRUE) 
lag3 <- stats::lag(data, k = -1) 
start(lag3)[1] 

## [1] 1970 

start(lag1)[1] == start(lag3)[1] 

## [1] FALSE 

Wszelkie sugestie są bardzo mile widziane. Jedyne moje dotychczasowe rozwiązanie to restartować sesję R pomiędzy obliczaniem lag1 i lag2.

Oto moja sesja:

## setting value      
## version R version 3.2.0 (2015-04-16) 
## system i386, mingw32    
## ui  RTerm      
## language (EN)       
## collate English_Canada.1252   
## tz  America/New_York    
## 
## package * version date  source   
## assertthat 0.1  2013-12-06 CRAN (R 3.2.0) 
## bitops  1.0-6 2013-08-17 CRAN (R 3.2.0) 
## DBI   0.3.1 2014-09-24 CRAN (R 3.2.0) 
## devtools  1.8.0 2015-05-09 CRAN (R 3.2.0) 
## digest  0.6.8 2014-12-31 CRAN (R 3.2.0) 
## dplyr  0.4.1 2015-01-14 CRAN (R 3.2.0) 
## evaluate  0.7  2015-04-21 CRAN (R 3.2.0) 
## formatR  1.2  2015-04-21 CRAN (R 3.2.0) 
## git2r  0.10.1 2015-05-07 CRAN (R 3.2.0) 
## htmltools 0.2.6 2014-09-08 CRAN (R 3.2.0) 
## httr  * 0.6.1 2015-01-01 CRAN (R 3.2.0) 
## knitr  1.10.5 2015-05-06 CRAN (R 3.2.0) 
## magrittr  1.5  2014-11-22 CRAN (R 3.2.0) 
## memoise  0.2.1 2014-04-22 CRAN (R 3.2.0) 
## Rcpp   0.11.6 2015-05-01 CRAN (R 3.2.0) 
## RCurl  1.95-4.6 2015-04-24 CRAN (R 3.2.0) 
## rmarkdown 0.6.1 2015-05-07 CRAN (R 3.2.0) 
## rversions 1.0.0 2015-04-22 CRAN (R 3.2.0) 
## stringi  0.4-1 2014-12-14 CRAN (R 3.2.0) 
## stringr  1.0.0 2015-04-30 CRAN (R 3.2.0) 
## XML   3.98-1.1 2013-06-20 CRAN (R 3.2.0) 
## yaml   2.1.13 2014-06-12 CRAN (R 3.2.0) 

Próbowałem zostały również unloadNamespace, jak sugeruje @BondedDust:

unloadNamespace("dplyr") 
lag4 <- stats::lag(data, k = -1) 

## Warning: namespace 'dplyr' is not available and has been replaced 
## by .GlobalEnv when processing object 'sep' 

start(lag4)[1] 

## [1] 1970 

start(lag1)[1] == start(lag4)[1] 

## [1] FALSE 
+0

'Odłączenie' może nie być w pełni skuteczne. Generalnie używam 'unloadNamespace'. (Ale próbowałem i to było nieskuteczne.) –

+0

Dzięki za sugestię. Nadal jednak mam 'start = 1970'. Ale dodałem tę opcję do powyższego pytania. –

+1

Tak. Zgadzam się, to jest zagadkowe. 'GetAnywhere (lag.default)' z dPly załadowanych retruns: '2 różnych obiektów dopasowanie 'lag.default' znaleziono w następujących miejscach zarejestrowane metodą S3 opóźnienia z nazw dplyr nazw: dplyr nazw: Statystyka Zastosowanie [ ], aby wyświetlić jedną z nich ". Wydaje się, że dplyr nadpisuje lag.default i nie daje ostrzeżenia o tym. –

Odpowiedz

18

Pakiet dplyr skutecznie nadpisywania 'lag'. Mechanizm wysyłkowy nie znajduje się w rzeczywistości, ponieważ tak naprawdę nie ma funkcji o tej nazwie, tylko dwie kopie lag.default, jedna w "stats" i jedna w "dplyr", a kopia "dplyr" znajduje się pierwsza. Można wymusić wersję można znaleźć statystyki z wykorzystaniem ::: -mechanism:

> lag2 <- stats::lag.default(data, k = -1) 
Error: 'lag.default' is not an exported object from 'namespace:stats' 

> lag2 <- stats:::lag.default(data, k = -1) 
> stats::start(lag2)[1] 
[1] 1971 

dplyr:::lag.default nie korzysta z szeregów czasowych określonych funkcji. Nie jestem w stanie wyjaśnić, dlaczego unloadNamespace nie usunąć definicję z funkcji, ale wciąż jest tam:

> unloadNamespace("dplyr") 
> getAnywhere(lag.default) 
2 differing objects matching ‘lag.default’ were found 
in the following places 
    registered S3 method for lag from namespace dplyr 
    namespace:stats 
Use [] to view one of them 

Dalsze niesamowitość: Po rozładunku dply -namespace widzę tak:

> environment(getAnywhere(lag.default)[1]) 
<environment: namespace:dplyr> 
> environment(getAnywhere(lag.default)[2]) 
<environment: namespace:dplyr> 
> environment(getAnywhere(lag.default)[3]) 
<environment: namespace:stats> 

(I następnie ponowne uruchomienie i załadunku dplyr, widzę tę samą pozorną podwójnego zapisu)

jest też coś dziwnego na stronie pomocy dla dplyr::lag.

> help(lag,pac=dplyr) 
No documentation for ‘lag’ in specified packages and libraries: 
you could try ‘??lag’ 
> help(`lag`,pac=`dplyr`) 
No documentation for ‘lag’ in specified packages and libraries: 
you could try ‘??lag’ 
> help(`lag.default`,pac=`dplyr`) # This finally succeeds! 

Patrząc na github (po stwierdzeniu, że mam najnowszą wersję dplyra na CRAN), widzę, że był to problem dla procesu R CMD check: https://github.com/hadley/dplyr/commit/f8a46e030b7b899900f2091f41071619d0a46288. Podobno lag.default nie zostanie nadpisany w przyszłych wersjach, ale lag zamaskuje wersję stats. Zastanawiam się, co stanie się z lag.zoo i lag.zooreg. Może ogłosi również, że nadpisanie lub maskowanie po załadowaniu paczki?

+0

To prawda! Bardzo dziękuję za pomoc. –

+1

FYI, ostatnio wpadłem na ten problem z pakietem "zoo". Co ciekawe, kiedy ładuję 'dplyr' po' zoo', 'lag.zoo' wydaje się być maskowany, chociaż NIE ma ostrzeżenia. 42-do pracy jest nadal ważne, tj. 'Zoo ::: lag.zoo (x, n)'. –

Powiązane problemy