Mengapa menggunakan purrr :: map bukan lapply?

Apakah ada alasan mengapa saya harus menggunakannya

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

dari pada

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

outputnya harus sama dan tolok ukur yang saya buat nampaknya menunjukkan bahwa lapplysedikit lebih cepat (harus sesuai dengan mapkebutuhan untuk mengevaluasi semua input non-standar-evaluasi).

Jadi apakah ada alasan mengapa untuk kasus sederhana seperti itu saya benar-benar harus mempertimbangkan untuk beralih ke purrr::map? Saya tidak bertanya di sini tentang suka atau tidak suka seseorang tentang sintaks, fungsi lain yang disediakan oleh purrr dll, tetapi hanya tentang perbandingan purrr::mapdengan lapplyasumsi menggunakan evaluasi standar, yaitu map(<list-like-object>, function(x) <do stuff>). Apakah ada kelebihan yang purrr::mapdimiliki dalam hal kinerja, penanganan pengecualian, dll.? Komentar di bawah ini menunjukkan bahwa tidak, tetapi mungkin seseorang dapat menguraikan sedikit lebih banyak?

Jika satu-satunya fungsi yang Anda gunakan dari purr adalah map(), maka tidak, keuntungannya tidak besar. Seperti yang ditunjukkan oleh Rich Pauloo, keuntungan utama map()adalah bantuan yang memungkinkan Anda menulis kode ringkas untuk kasus khusus umum:

• ~ . + 1 setara dengan function(x) x + 1

• list("x", 1)setara dengan function(x) x[["x"]][[1]]. Pembantu ini sedikit lebih umum daripada [[- lihat ?pluckdetailnya. Untuk persegi panjang data , .defaultargumen ini sangat membantu.

Tetapi sebagian besar waktu Anda tidak menggunakan satu *apply()/ map() fungsi, Anda menggunakan banyak dari mereka, dan keuntungan dari purrr adalah konsistensi yang jauh lebih besar antara fungsi. Sebagai contoh:

• Argumen pertama lapply()adalah data; argumen pertama mapply()adalah fungsi. Argumen pertama untuk semua fungsi peta selalu data.

• Dengan vapply(),, sapply()dan mapply()Anda dapat memilih untuk menekan nama pada output dengan USE.NAMES = FALSE; tetapi lapply()tidak memiliki argumen itu.

• Tidak ada cara yang konsisten untuk meneruskan argumen yang konsisten ke fungsi mapper. Sebagian besar fungsi menggunakan ...tetapi mapply()menggunakan MoreArgs(yang Anda harapkan dipanggil MORE.ARGS), dan Map(), Filter()dan Reduce()berharap Anda membuat fungsi anonim baru. Dalam fungsi peta, argumen konstan selalu muncul setelah nama fungsi.

• Hampir setiap fungsi purrr adalah tipe stabil: Anda dapat memprediksi tipe output secara eksklusif dari nama fungsi. Ini tidak benar untuk sapply()atau mapply(). Ya ada vapply(); tapi tidak ada padanan untuk mapply().

Anda mungkin berpikir bahwa semua perbedaan kecil ini tidak penting (seperti beberapa orang berpikir bahwa tidak ada keuntungan untuk merangkai ekspresi reguler basis R), tetapi dalam pengalaman saya mereka menyebabkan gesekan yang tidak perlu saat pemrograman (perintah argumen yang berbeda selalu digunakan untuk trip saya), dan mereka membuat teknik pemrograman fungsional lebih sulit untuk dipelajari karena juga ide-ide besar, Anda juga harus belajar banyak detail insidental.

Purrr juga mengisi beberapa varian peta praktis yang tidak ada di basis R:

• modify()mempertahankan tipe data yang digunakan [[<-untuk memodifikasi "di tempat". Sehubungan dengan _ifvarian ini memungkinkan untuk kode (IMO indah) sepertimodify_if(df, is.factor, as.character)

• map2()memungkinkan Anda untuk memetakan sekaligus xdan y. Ini membuatnya lebih mudah untuk mengekspresikan ide-ide seperti map2(models, datasets, predict)

• imap()memungkinkan Anda untuk memetakan secara bersamaan xdan indeksnya (baik nama atau posisi). Ini memudahkan (misalnya) memuat semua csvfile dalam direktori, menambahkan filenamekolom ke masing-masing file .

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

• walk()mengembalikan inputnya tanpa terlihat; dan berguna ketika Anda memanggil fungsi untuk efek sampingnya (yaitu menulis file ke disk).

Belum lagi pembantu lainnya seperti safely()dan partial().

Secara pribadi, saya menemukan bahwa ketika saya menggunakan purrr, saya dapat menulis kode fungsional dengan lebih sedikit gesekan dan kemudahan yang lebih besar; itu mengurangi kesenjangan antara memikirkan ide dan mengimplementasikannya. Tetapi jarak tempuh Anda mungkin berbeda; tidak perlu menggunakan purrr kecuali itu benar-benar membantu Anda.

Microbenchmark

Ya, map()sedikit lebih lambat dari lapply(). Tetapi biaya menggunakan map()atau lapply()didorong oleh apa yang Anda pemetaan, bukan biaya overhead untuk melakukan loop. Microbenchmark di bawah ini menunjukkan bahwa biaya map()dibandingkan dengan lapply()sekitar 40 ns per elemen, yang tampaknya tidak berdampak material terhadap sebagian besar kode 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

Membandingkan purrrdan lapplybermuara pada kenyamanan dan kecepatan .

1. purrr::mapsecara sintaksis lebih nyaman daripada lapply

ekstrak elemen kedua dari daftar

map(list, 2)  

yang sebagai @F. Privé tunjukkan, sama dengan:

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

dengan lapply

lapply(list, 2) # doesn't work

kita harus melewati fungsi anonim ...

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

... atau seperti yang ditunjukkan @RichScriven, kami memberikan [[argumenlapply

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

Jadi jika menemukan diri Anda menerapkan fungsi ke banyak daftar menggunakan lapply, dan bosan mendefinisikan fungsi kustom atau menulis fungsi anonim, kenyamanan adalah salah satu alasan untuk memilih purrr.

2. Jenis-fungsi peta spesifik hanya banyak baris kode

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

Masing-masing fungsi peta tipe spesifik ini mengembalikan vektor, bukan daftar yang dikembalikan oleh map()dan lapply(). Jika Anda berurusan dengan daftar vektor bersarang, Anda dapat menggunakan fungsi peta khusus ini untuk menarik vektor secara langsung, dan memaksa vektor langsung ke vektor int, dbl, chr. Versi dasar R akan terlihat seperti as.numeric(sapply(...)), as.character(sapply(...)), dll

map_<type>Fungsi - fungsinya juga memiliki kualitas yang berguna bahwa jika mereka tidak dapat mengembalikan vektor atom dari tipe yang ditunjukkan, mereka gagal. Ini berguna ketika mendefinisikan aliran kontrol yang ketat, di mana Anda ingin fungsi gagal jika [entah bagaimana] menghasilkan tipe objek yang salah.

3. Kesamping kenyamanan, lapplyadalah [sedikit] lebih cepat daripadamap

Menggunakan purrrfungsi kenyamanan, sebagai @F. Privé menunjukkan memperlambat pemrosesan sedikit. Mari kita berlomba masing-masing dari 4 kasus yang saya disajikan di atas

# 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)

Dan pemenangnya adalah....

lapply(list, `[[`, 2)

Singkatnya, jika kecepatan mentah adalah yang Anda cari: base::lapply(meskipun itu tidak jauh lebih cepat)

Untuk sintaks dan ekspresi yang sederhana: purrr::map

purrrTutorial yang sangat baik ini menyoroti kenyamanan tidak harus secara eksplisit menulis fungsi anonim saat menggunakan purrr, dan manfaat dari mapfungsi tipe-spesifik .

Jika kita tidak mempertimbangkan aspek selera (kalau tidak pertanyaan ini harus ditutup) atau konsistensi sintaksis, gaya dll. Jawabannya tidak, tidak ada alasan khusus untuk digunakan mapsebagai ganti lapplyatau varian lain dari keluarga yang berlaku, seperti yang lebih ketat vapply.

PS: Kepada orang-orang itu dengan sembrono downvoting, ingat saja OP menulis:

Saya tidak bertanya di sini tentang suka atau tidak suka seseorang tentang sintaks, fungsi-fungsi lain yang disediakan oleh purrr dll, tetapi hanya tentang perbandingan purrr :: map dengan sedikit asumsi dengan menggunakan evaluasi standar

Jika Anda tidak mempertimbangkan sintaks atau fungsi lain dari purrr, tidak ada alasan khusus untuk digunakan map. Saya menggunakan purrrdiri saya sendiri dan saya baik-baik saja dengan jawaban Hadley, tetapi ironisnya hal itu lebih penting daripada yang dikatakan OP di muka bahwa ia tidak bertanya.