Сравнение dplyr:: do/purrr:: map, какие преимущества?

При использовании broom я использовал для объединения dplyr::group_by и dplyr::do для выполнения действий по сгруппированным данным благодаря @drob. Например, установка линейной модели на автомобили в зависимости от их системы передач:

library("dplyr")
library("tidyr")
library("broom")

# using do()
mtcars %>%
  group_by(am) %>%
  do(tidy(lm(mpg ~ wt, data = .)))

# Source: local data frame [4 x 6]
# Groups: am [2]

#     am        term  estimate std.error statistic      p.value
#   (dbl)       (chr)     (dbl)     (dbl)     (dbl)        (dbl)
# 1     0 (Intercept) 31.416055 2.9467213 10.661360 6.007748e-09
# 2     0          wt -3.785908 0.7665567 -4.938848 1.245595e-04
# 3     1 (Intercept) 46.294478 3.1198212 14.838824 1.276849e-08
# 4     1          wt -9.084268 1.2565727 -7.229401 1.687904e-05

После прочтения недавнего сообщения от @hadley о tidyr v0.4.1 Я обнаружил, что то же самое можно достичь с помощью nest() и purrr::map()

Тот же пример, что и раньше:

by_am <- mtcars %>%
  group_by(am) %>%
  nest() %>%
  mutate(model = purrr::map(data, ~ lm(mpg ~ wt, data = .)))

by_am %>%
  unnest(model %>% purrr::map(tidy))

# Source: local data frame [4 x 6]

#      am        term  estimate std.error statistic      p.value
#   (dbl)       (chr)     (dbl)     (dbl)     (dbl)        (dbl)
# 1     1 (Intercept) 46.294478 3.1198212 14.838824 1.276849e-08
# 2     1          wt -9.084268 1.2565727 -7.229401 1.687904e-05
# 3     0 (Intercept) 31.416055 2.9467213 10.661360 6.007748e-09
# 4     0          wt -3.785908 0.7665567 -4.938848 1.245595e-04

Порядок изменился, но результаты совпадают.

Мне интересно, нужен ли какой-либо метод и каковы преимущества каждого из них.

Из моего короткого опыта:

  • сделать
    • индикатор выполнения, приятный, когда вычисляются многие модели.
    • @Комментарий Axeman: можно распараллелить с помощью multidplyr
    • меньший объект, но нужно повторно запустить, если мы хотим broom::glance fx.
  • карта
    • данные, подмножества и модели хранятся в пределах одного tbl_df
    • легко извлечь другой компонент моделей, даже если unnest() занимает немного времени.

Если у вас есть некоторые идеи/замечания, мы будем рады получить обратную связь.

Ответы