Навіщо використовувати purrr :: map замість lapply?

Чи є якась причина, чому я повинен використовувати

map(<list-like-object>, function(x) <do stuff>)

замість

lapply(<list-like-object>, function(x) <do stuff>)

висновок повинен бути однаковим, і показники, які я зробив, здаються, показують, що lapplyце трохи швидше (він повинен бути таким, як mapпотрібно оцінювати всі дані нестандартної оцінки).

То чи є причина, чому я для таких простих випадків насправді повинен розглянути питання про перехід purrr::map? Я не розпитую тут про власні симпатії чи невдоволення щодо синтаксису, інших функціональних можливостей, що надаються purrr тощо, а строго про порівняння purrr::mapз lapplyприпущенням використання стандартного оцінювання, тобто map(<list-like-object>, function(x) <do stuff>). Чи є якась перевага, яка purrr::mapмає продуктивність, обробку винятків тощо? Зауважені нижче коментарі говорять про те, що це не так, але, можливо, хтось міг би розробити трохи більше?

Якщо єдиною функцією, яку ви використовуєте від purrr, є map(), ні, переваги не суттєві. Як зазначає Річ Паулу, головна перевага map()- це помічники, які дозволяють писати компактний код для звичайних спеціальних випадків:

• ~ . + 1 еквівалентно function(x) x + 1

• list("x", 1)еквівалентно function(x) x[["x"]][[1]]. Ці помічники трохи більш загальні, ніж[[ - див. ?pluckПодробиці. Для rectangling даних , то .defaultаргумент особливо корисно.

Але більшу частину часу ви не використовуєте одну *apply()/ map() функцію, ви використовуєте купу їх, і перевага purrr полягає в набагато більшій узгодженості між функціями. Наприклад:

• Перший аргумент lapply()- це дані; Перший аргумент mapply()- це функція. Перший аргумент для всіх функцій карти - це завжди дані.

• З vapply(), sapply()іmapply() ви можете вибрати для придушення імен на виході з USE.NAMES = FALSE; але lapply()не має такого аргументу.

• Не існує послідовного способу передачі послідовних аргументів функції картографа. Більшість функцій використовують, ...але mapply()використовує MoreArgs(які, як ви очікуєте, викликаєте MORE.ARGS), і Map() , Filter()і Reduce()очікує, що ви створите нову анонімну функцію. У функціях карти постійний аргумент завжди приходить після назви функції.

• Практично кожна функція purrr є стабільною типу: ви можете прогнозувати тип виходу виключно з назви функції. Це не вірно для sapply()або mapply(). Так, є vapply(); але немає еквівалента для mapply().

Ви можете подумати, що всі ці незначні відмінності не важливі (так само, як деякі люди вважають, що немає переваги стрингер перед базовими R регулярними виразами), але, на мій досвід, вони викликають непотрібне тертя при програмуванні (різні аргументи наказу завжди використовуються для відключення мені), і вони ускладнюють вивчення функціональних методів програмування, тому що, як і великі ідеї, ви також повинні вивчити купу випадкових деталей.

Purrr також заповнює деякі зручні варіанти карт, які відсутні в базі R:

• modify()зберігає тип даних, використовуючи [[<-для зміни "на місці". У поєднанні з_if варіантом це дозволяє (наприклад, IMO красивий) кодmodify_if(df, is.factor, as.character)

• map2()дозволяє одночасно відображати карту над xі y. Це полегшує висловлення ідей на кшталт map2(models, datasets, predict)

• imap()дозволяє одночасно відображати карти xта його індекси (або імена, і позиції). Це дозволяє (наприклад) завантажувати всі csvфайли в каталог, додаючи filenameстовпчик до кожного.

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

• walk()повертає свій внесок невидимо; і корисно, коли ви викликаєте функцію для її побічних ефектів (тобто запису файлів на диск).

Не кажучи вже про інших помічників, як safely()іpartial() .

Особисто я вважаю, що під час використання purrr я можу писати функціональний код із меншим тертям та більшою легкістю; це зменшує розрив між продумуванням ідеї та її реалізацією. Але ваш пробіг може відрізнятися; немає потреби використовувати purrr, якщо це насправді не допоможе вам.

Мікроблоки

Так, map()трохи повільніше, ніж lapply(). Але вартість використання map()або lapply()залежить від того, що ви картографуєте, а не накладні витрати виконання циклу. Наведений нижче мікроелемент говорить про те, що map()порівняно з вартістю lapply()приблизно 40 нс на елемент, що, мабуть, навряд чи істотно вплине на більшість 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

Порівняння purrrта lapplyзведення до зручності та швидкості .

1. purrr::mapсинтаксично зручніше ніж скупо

витягнути другий елемент списку

map(list, 2)  

який як @F. Пріве зазначив, те саме, що:

map(list, function(x) x[[2]])

з lapply

lapply(list, 2) # doesn't work

нам потрібно пройти анонімну функцію ...

lapply(list, function(x) x[[2]])  # now it works

... або як зазначав @RichScriven, ми передаємо це [[як аргументlapply

lapply(list, `[[`, 2)  # a bit more simple syntantically

Тож якщо ви знайдете можливість застосовувати функції до багатьох списків, використовуючи lapplyі не в змозі визначити власну функцію або записати анонімну функцію, зручність є однією з причин перевагиpurrr .

2. Спеціальна карта функціонує просто багато рядків коду

• map_chr()
• map_lgl()
• map_int()
• map_dbl()
• map_df()

Кожна з цих функцій карт, специфічних для типу, повертає вектор, а не списки, повернуті map()і lapply(). Якщо ви маєте справу з вкладеними списками векторів, ви можете використовувати ці функції, характерні для типу, для витягування векторів безпосередньо та примусових векторів безпосередньо у вектори int, dbl, chr. Базова версія R виглядатиме приблизно так as.numeric(sapply(...)),as.character(sapply(...)) і так далі

The map_<type> функції також мають корисне якість, якщо вони не можуть повернути атомний вектор зазначеного типу, вони зазнають невдачі. Це корисно при визначенні строгого потоку управління, коли ви хочете, щоб функція вийшла з ладу, якщо вона [якось] генерує неправильний тип об'єкта.

3. Зручність убік, lapply[трохи] швидше, ніжmap

Використання purrrфункцій зручності, як @F. Privé зазначив, що трохи сповільнює обробку. Давайте розберемося по кожному з 4-х випадків, які я подав вище.

# devtools::install_github("jennybc/repurrrsive")
library(repurrrsive)
library(purrr)
library(microbenchmark)
library(ggplot2)

mbm <- microbenchmark(
lapply       = lapply(got_chars[1:4], function(x) x[[2]]),
lapply_2     = lapply(got_chars[1:4], `[[`, 2),
map_shortcut = map(got_chars[1:4], 2),
map          = map(got_chars[1:4], function(x) x[[2]]),
times        = 100
)
autoplot(mbm)

А переможець -….

lapply(list, `[[`, 2)

Підсумовуючи, якщо швидкість сировини - це те, що ви шукаєте: base::lapply (хоча це не те, що набагато швидше)

Для простого синтаксису та виразності: purrr::map

Цей чудовий purrrпідручник підкреслює зручність відсутності явного виписування анонімних функцій під час використання purrrта переваги функцій, характерних для типу map.

Якщо ми не розглядаємо аспекти смаку (інакше це питання слід закрити) або послідовність синтаксису, стиль тощо, відповідь "ні", немає особливих причин використовувати mapзамість lapplyінших варіантів сімейства застосувань, наприклад, суворішого vapply.

PS: Тим людям, які безоплатно звертаються, просто пам’ятайте, що ОП писав:

Я не запитую тут про власні симпатії чи не подобається синтаксис, інші функціональні можливості, які надає purrr і т.д., але строго про порівняння purrr :: map зі скромним припущенням, використовуючи стандартне оцінювання

Якщо ви не враховуєте синтаксис та інші функціональні можливості purrr, немає особливих причин для використання map. Я використовую purrrсебе, і я чудово відповідаю на відповідь Хедлі, але це іронічно переходить до тих самих речей, які ОП заявила наперед, про що він не запитував.