r dplyr tidyr broom

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.

Si tiene algunas ideas / comentarios, estará encantado de tener algunos comentarios.