Jeśli jedyną funkcją używaną przez purrr jest map(), to nie, korzyści nie są znaczące. Jak zaznacza Rich Pauloo, głównym zaletą map() są helpery, które pozwalają na pisanie kompaktowych kod typowych przypadków szczególnych:

• ~ . + 1 jest odpowiednikiem function(x) x + 1

• list("x", 1) jest równoważne function(x) x[["x"]][[1]]. Te pomocnicy są nieco bardziej ogólni niż [[ - Zobacz ?pluck po szczegóły. Dla danych rectangling , the .default argument jest szczególnie pomocne.

Ale przez większość czasu nie używasz jednego *apply() / map() funkcji, używasz kilku z nich, a zaletą purrr jest znacznie większa spójność między funkcjami. Na przykład:

• Pierwszym argumentem do lapply() są dane; pierwszym argumentem do mapply() jest funkcją. Pierwszy argument do wszystkich funkcji map jest zawsze dane.

• Z vapply(), sapply(), i mapply() możesz wybrać wymazywanie nazw na wyjście z USE.NAMES = FALSE; ale lapply() nie ma takiego argumentu.

• Nie ma spójnego sposobu przekazywania spójnych argumentów na funkcja mapera. Większość funkcji używa ..., ale mapply() używa MoreArgs (którego można się spodziewać, że będzie się nazywać MORE.ARGS), oraz Map(), Filter() i Reduce() oczekuję, że stworzysz nowy funkcja anonimowa. W funkcjach map zawsze pojawia się argument stały po nazwie funkcji.

• Prawie każda funkcja purrr jest typu stabilna: można przewidzieć na Typ wyjścia wyłącznie z nazwy funkcji. Nie jest to prawdą dla sapply() lub mapply(). Tak, jest vapply(); ale nie ma odpowiednik dla mapply().

Możesz myśleć, że wszystkie te drobne rozróżnienia nie są ważne (tak jak niektórzy myślą, że nie ma przewagi stringr nad bazowych wyrażeń regularnych R), ale z mojego doświadczenia wynika, że powodują niepotrzebne tarcia podczas programowania (odmienne rozkazy argumentów zawsze używane do trip me up), i sprawiają, że funkcjonalne techniki programowania trudniejsze do ucz się, ponieważ oprócz wielkich pomysłów, Musisz również nauczyć się kilku przypadkowych szczegółów.

Purrr wypełnia również kilka przydatnych wariantów map, których nie ma w bazie R:

• modify() zachowuje typ danych używając [[<- do modyfikacji "in miejsce". W połączeniu z wariantem _if pozwala to na (IMO piękny) Kod jak modify_if(df, is.factor, as.character)

• map2() pozwala na jednoczesne mapowanie x i y. To sprawia, że łatwiej jest wyrażać idee takie jak map2(models, datasets, predict)

• imap() pozwala na jednoczesne mapowanie x i jego indeksów (nazwiska lub stanowiska). To ułatwia (np.) załadowanie wszystkich csv pliki w katalogu, dodając do każdego kolumny filename.

  dir("\\.csv$") %>%
    set_names() %>%
    map(read.csv) %>%
    imap(~ transform(.x, filename = .y))
  

• walk() zwraca jego wejście niewidocznie; i jest przydatny, gdy jesteś wywołanie funkcji dla jej efektów ubocznych (np. zapisywanie plików do dysk).

Nie wspominając o innych pomocnikach jak safely() i partial().

Osobiście uważam, że kiedy używam purrr, mogę napisać kod funkcjonalny z mniejszym tarciem i większą łatwością; zmniejsza lukę między wymyślanie pomysłu i wdrażanie go. Ale przebieg może się różnić; nie ma potrzeby, aby używać purrr, chyba że rzeczywiście pomaga.

Microbenchmarks

Tak, map() jest nieco wolniejszy niż lapply(). Ale koszt korzystania map() lub lapply() jest napędzany przez to, co mapujesz, a nie nad głową wykonywania pętli. Na microbenchmark poniżej sugeruje, że koszt z map() w porównaniu do lapply() wynosi około 40 ns na pierwiastek, co wydaje się mało prawdopodobne, aby miało to istotny wpływ na większość kodu R.

library(purrr)
n <- 1e4
x <- 1:n
f <- function(x) NULL

mb <- microbenchmark::microbenchmark(
  lapply = lapply(x, f),
  map = map(x, f)
)
summary(mb, unit = "ns")$median / n
#> [1] 490.343 546.880