Comparación entre dplyr:: do/purrr:: map, ¿qué ventajas?
tidyr broom (0)
Cuando utilizaba broom
, solía combinar dplyr::group_by
y dplyr::do
para realizar acciones en datos agrupados gracias a @drob. Por ejemplo, ajustar un modelo lineal a los automóviles en función de su sistema de engranajes:
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
Después de leer la publicación reciente de @hadley sobre tidyr v0.4.1
, descubrí que se podría lograr lo mismo usando nest()
y purrr::map()
El mismo ejemplo que antes:
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
El ordenamiento cambió, pero los resultados son los mismos.
Dado que ambos abordan en gran medida el mismo caso de uso, me pregunto si se van a apoyar ambos enfoques en el futuro. ¿Se convertirá el método en el método tidyverse
canónico? Si uno no se considera canónico, ¿qué casos de uso requieren que ambos enfoques continúen siendo compatibles?
De mi corta experiencia:
- hacer
- Barra de progreso, agradable cuando se calculan muchos modelos.
- Comentario de @Axeman: se puede paralelizar usando
multidplyr
- Objeto más pequeño, pero necesitamos volver a ejecutarlo si queremos
broom::glance
fx.
- mapa
- los datos, subconjuntos y modelos se guardan dentro de un
tbl_df
- Es fácil extraer otro componente de los modelos, incluso si
unnest()
toma un poco de tiempo.
- los datos, subconjuntos y modelos se guardan dentro de un
Si tiene algunas ideas / comentarios, estará encantado de tener algunos comentarios.