为什么要用purrr::map而不是lapply？

Question

我有什么理由使用

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

而不是

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

输出应该是相同的，我所做的基准测试似乎表明lapply稍微快一点（它应该是地图需要评估所有非标准评估输入）。

那么，对于如此简单的情况，有什么理由让我考虑切换到< code>purrr::map呢？我在这里不是问你喜欢或不喜欢purrr提供的语法和其他功能。，但严格来说是关于< code>purrr::map与< code>lapply的比较，假设使用标准评估，即< code>map(

Answer 1

如果我们不考虑品味(否则这个问题应该结束)或语法一致性、风格等方面，答案是否定的，没有特殊的理由使用< code>map而不是< code>lapply或apply系列的其他变体，如更严格的< code>vapply。

PS：对于那些无端投下票的人，只要记住OP写道：

我在这里并不是问你喜欢或不喜欢purrr等提供的语法、其他功能，而是严格地比较purrr：：map与lapply假设使用标准评估

如果你不考虑语法或purrr的其他功能，那么使用map就没有特殊的理由。我自己使用呼噜声，我对哈德利的答案很好，但具有讽刺意味的是，它忽略了OP事先声明他没有问的事情。

Answer 2

提取列表的第二个元素

map(list, 2)  

正如普里维@F所指出的，这与以下情况相同：

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

使用lapplication

lapply(list, 2) # doesn't work

我们需要传递一个匿名函数。。。

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

...或者正如@RichScriven指出的，我们将< code>[[作为参数传递给< code>lapply

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

因此，如果您发现自己正在使用lapply将函数应用到许多列表中，并且厌倦了定义自定义函数或编写匿名函数，那么方便是支持purrr的原因之一。

• map_chr（）
• map_lgl（）
• map_int（）
• map_dbl（）
• map_df（）

这些特定于类型的映射函数中的每一个都返回一个向量，而不是map（）和lapplication（）返回的列表。如果您正在处理嵌套的向量列表，您可以使用这些特定于类型的映射函数直接提取向量，并将向量直接强制转换为int、dbl、chr向量。基本R版本类似于as.numeric（sapplication（…））、as.character（sapplication（…））等。

<代码>地图_

正如 Privé @F指出的那样，使用 purrr 的便利功能会稍微减慢处理速度。让我们对我上面介绍的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)

总而言之，如果原始速度是你所追求的：基础：：拉普利（尽管它没有那么快）

为了简单的语法和表达：purrr::map

这篇优秀的< code>purrr教程强调了使用< code>purrr时不必显式写出匿名函数的便利性，以及特定于类型的< code>map函数的好处。

Answer 3

如果您在purrr中使用的唯一函数是map（），那么不，优势并不明显。正如Rich Pauloo所指出的那样，map（）的主要优点是它可以帮助您为常见的特殊情况编写紧凑的代码：

>

~.1相当于函数（x）x 1>）

< code>list("x "，1)等价于< code > function(x)x[[" x "]][[1]]。这些助手比< code>[[ - see ？详情请点击。对于数据矩形化，< code >。default参数特别有用。

但大多数时候，您没有使用单个*apply（）/map（）函数，而是使用了一组函数，purrr的优点是函数之间的一致性更强。例如：

>

lapply（）的第一个参数是数据；mapply（）的第一个参数是函数。所有映射函数的第一个参数始终是数据。

使用vapplication（）、sapplication（）和mapplication（），您可以选择使用USE.NAMES=FALSE来抑制输出上的名称；但是lapplication（）没有这个参数。

没有一致的方法将一致的参数传递给mapper函数。大多数函数使用…，但mapplication（）使用MoreArgs（您希望将其称为MORE.ARGS），而Map（）、Filter（）和Reduce（）希望您创建一个新的匿名函数。在map函数中，常量参数总是位于函数名称之后。

几乎每个 purrr 函数都是类型稳定的：您可以仅从函数名称预测输出类型。对于 sapply（） 或映射 （）而言，情况并非如此。是的，有 vapply（）;但是没有等效的映射（）。

你可能会认为所有这些小的区别都不重要（就像有些人认为stringr相对于基本R正则表达式没有优势一样），但根据我的经验，它们在编程时会引起不必要的摩擦（不同的论证顺序总是用来绊倒我），它们使函数式编程技术更难学习，因为除了大想法， 你还必须学习一堆偶然的细节。

Purrr还填充了基础R中缺少的一些方便的贴图变体：

>

修改（）使用[[

map2（） 允许您同时映射 x 和 y。这使得表达像map2（模型，数据集，预测）这样的想法变得更加容易。

imap（）允许您同时映射x及其索引（名称或位置）。这使得（例如）加载目录中的所有csv文件变得容易，并为每个文件添加一个文件名列。

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

walk（）不可见地返回其输入；当您为函数的副作用（即将文件写入磁盘）调用函数时，它非常有用。

更不用说像< code>safely()和< code>partial()这样的其他助手了。

就我个人而言，我发现当我使用purrr时，我可以用更少的摩擦和更容易的方式编写函数代码；它减少了构思和实施之间的差距。但您的里程数可能会有所不同；没有必要使用purrr，除非它确实对你有帮助。

是的，map（）略慢于lapply（）。但是，使用map（）或lapply（）的成本是由您映射的内容决定的，而不是执行循环的开销。下面的微基准表明，与lapply（）相比，map（）的成本约为每个元素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