Dplyr:: select вызовы функции с помощью MASS:: select

Ответ 1

Как сказал Паскаль, следующие работы

require(MASS)
require(dplyr)
mtcars %>%
   dplyr::select(mpg)

Ответ 2

Это происходит со мной чаще, чем я должен признать. dplyr сталкивается с MASS::select, plyr::summarise и stats::filter между прочим, особенно при загрузке пакетов, которые загружают одну из этих библиотек через библиотеку (они не должны, но некоторые все еще делают), или когда вы загружаете dplyr в свой .Rprofile (не надо!). И это может привести к довольно неясным проблемам, а не всегда сообщению об ошибке, особенно конфликтует с plyr.

Я только недавно узнал о функции conflicts(). Это полезно, но конфликты "over-reports", когда два пакета имеют одинаковые функции, например. tidyr:: %>% и dplyr:: %>%.

Итак, я написал функцию, чтобы сказать мне, схожу ли я с ума или действительно ли конфликт вызывает текущую ошибку. Он не только проверяет наличие конфликтов, но проверяет, является ли определенный желаемый пакет "сверху" и действительно ли функциональные тела отличаются.

Он делает это для dplyr по умолчанию, но вы можете указать другой пакет, используя параметр want_package. Например, я часто сработал recode и alpha, которые повторно используются во многих пакетах.

Использование просто: amigoingmad().

По умолчанию он также автоматически "фиксирует" вещи, если dplyr не "сверху", используя следующие команды:

detach("package:dplyr", character.only = TRUE)
library("dplyr", character.only = TRUE)

Обратите внимание, что функция будет сообщать, если заданная пользователем функция блокирует dplyr, но не исправляет это автоматически для безопасности (просто удалите функцию в этом случае).

До сих пор это решение не вызывало у меня никаких проблем. Конечно, я бы не стал использовать это в производственном коде, но когда вы отлаживаете файл .Rmd и, возможно, случайно испортили заказ на загрузку, это быстрый способ узнать.

Если вы хотите это в пакете:

devtools::install_github("rubenarslan/formr")

Ответ 3

Если вы загрузите первую библиотеку MASS и вторую dplyr one

library (MASS)
library (dplyr)

то первая версия функции select в вашей сессии searchpaths () будет той, что находится в библиотеке dplyr.

Следовательно

select(mtcars, mpg)

будет работать как

dplyr::select(mtcars, mpg)

Ответ 4

Как и в случае с комментарием KFB выше, я нашел одно простое решение: (1) загрузить ваши пакеты, (2) не беспокоиться о порядке (что может быть сложно с зависимостями), (3) назначить приоритет любому пакету, который вы ' я предпочел бы "владеть" пространством имен:

select <- dplyr::select
filter <- dplyr::filter

Например, посмотрите, как меняется environment: namespace ниже:

library(MASS)
select

  function (obj) 
  UseMethod("select")
  <bytecode: 0x7fbe822811b8>
  <environment: namespace:MASS>

select <- dplyr::select
select

  function (.data, ...) 
  {
      UseMethod("select")
  }
  <bytecode: 0x7fbe7c4a2f08>
  <environment: namespace:dplyr>

Ответ 5

Элегантное решение - использовать пакет conflicted, который:

• генерирует информативные сообщения об ошибках, когда возникают конфликты пространства имен
• предлагает явную функцию для назначения приоритета пространства имен

Смотрите пример кода ниже частично из https://github.com/r-lib/conflicted

# install.packages("devtools")
devtools::install_github("r-lib/conflicted")

library(conflicted)
library(dplyr)

# example of informative error message
filter(mtcars, cyl == 8)
#> Error: [conflicted] 'filter' found in 2 packages.
#> Either pick the one you want with '::' 
#> * dplyr::filter
#> * stats::filter
#> Or declare a preference with 'conflicted_prefer()'
#> * conflict_prefer("filter", "dplyr")
#> * conflict_prefer("filter", "stats")

# example of assigning priority with conflict_prefer function
conflict_prefer("filter", "dplyr")

filter(mtcars, cyl == 8) %>% head(2)
#    mpg cyl  disp  hp drat   wt  qsec vs am gear carb
# 1 18.7   8 360.0 175 3.15 3.44 17.02  0  0    3    2
# 2 14.3   8 360.0 245 3.21 3.57 15.84  0  0    3    4