r4ds/lists.Rmd

784 lines
26 KiB
Plaintext
Raw Normal View History

2015-11-09 20:33:07 +08:00
---
layout: default
2015-11-19 02:03:51 +08:00
title: List manipulation
2015-11-09 20:33:07 +08:00
output: bookdown::html_chapter
---
```{r setup, include=FALSE}
library(purrr)
set.seed(1014)
options(digits = 3)
2015-11-19 02:03:51 +08:00
source("images/embed_jpg.R")
2015-11-09 20:33:07 +08:00
```
# Lists
2015-11-19 02:03:51 +08:00
In this chapter, you'll learn how to handle lists, the data structure R uses for complex, hierarchical objects. You've already familiar with vectors, R's data structure for 1d objects. Lists extend these ideas to model objects that are like trees. Lists allow you to do this because unlike vectors, a list can contain other lists.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
If you've worked with list-like objects before, you're probably familiar with the for loop. I'll talk a little bit about for loops here, but the focus will be functions from the __purrr__ package. purrr makes it easier to work with lists by eliminating common for loop boilerplate so you can focus on the specific details. This is the same idea as the apply family of functions in base R (`apply()`, `lapply()`, `tapply()`, etc), but purrr is more consistent and easier to learn.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
The goal of using purrr functions instead of for loops is to allow you break common list manipulation challenges into independent pieces:
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
1. How can you solve the problem for a single element of the list? Once
you've solved that problem, purrr takes care of generalising your
solution to every element in the list.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
1. If you're solving a complex problem, how can you break it down into
bite sized pieces that allow you to advance one small step towards a
solution? With purrr, you get lots of small pieces that you can
combose together with the pipe.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
This structure makes it easier to solve new problems. It also makes it easier to understand your solutions to old problems when you re-read your old code.
2015-11-09 20:33:07 +08:00
<!--
## Warm ups
* What does this for loop do?
* How is a data frame like a list?
* What does `mean()` mean? What does `mean` mean?
* How do you get help about the $ function? How do you normally write
`[[`(mtcars, 1) ?
2015-11-09 22:58:33 +08:00
* Argument order
2015-11-09 20:33:07 +08:00
-->
## List basics
2015-11-19 02:03:51 +08:00
To create a list, you use the `list()` function:
```{r}
x <- list(1, 2, 3)
str(x)
```
Unlike the atomic vectors, `lists()` can contain a mix of objects:
```{r}
y <- list("a", 1L, 1.5, TRUE)
str(y)
```
`str()` is very helpful when looking at lists because it focusses on the structure, not the contents.
Lists can even contain other lists!
```{r}
z <- list(list(1, 2), list(3, 4))
str(z)
```
There are three ways to subset a list:
* `[` extracts a sub-list. The result will always be a list.
```{r}
str(y[1:3])
str(y[1])
```
* `[[` extracts a single component from a list.
```{r}
str(y[[1]])
str(y[[3]])
```
* `$` is a shorthand for extracting named elements of a list. It works
very similarly to `[[` except that you don't need to use quotes.
```{r}
a <- list(x = 1:2, y = 3:4)
a$x
a[["y"]]
```
It's easy to get confused between `[` and `[[`, but understanding the difference is critical when working with lists. A few months ago I stayed at a hotel with a pretty interesting pepper shaker that I hope will help remember:
```{r, echo = FALSE}
embed_jpg("images/pepper.jpg", 300)
```
If this pepper shaker is your list `x`, then, `x[1]` is a pepper shaker containing a single pepper packet:
```{r, echo = FALSE}
embed_jpg("images/pepper-1.jpg", 300)
```
`x[2]` would look the same, but would contain the second packet. `x[1:2]` would be a pepper shaker containing two pepper packets.
`x[[1]]` is:
```{r, echo = FALSE}
embed_jpg("images/pepper-2.jpg", 300)
```
If you wanted to get the content of the pepper package, you'd need `x[[1]][[1]]`:
```{r, echo = FALSE}
embed_jpg("images/pepper-3.jpg", 300)
```
2015-11-09 20:33:07 +08:00
## A common pattern of for loops
2015-11-19 02:03:51 +08:00
Lets start by creating a stereotypical list: an eight element list where each element contains a random vector of random length. (You'll learn `rerun()` later.)
2015-11-09 20:33:07 +08:00
```{r}
2015-11-19 02:03:51 +08:00
x <- rerun(8, runif(sample(5, 1)))
2015-11-09 20:33:07 +08:00
str(x)
```
2015-11-19 02:03:51 +08:00
Imagine we want to compute the length of each element in this list. One way to do that is with a for loop:
2015-11-09 20:33:07 +08:00
```{r}
2015-11-19 02:03:51 +08:00
results <- vector("integer", length(x))
2015-11-09 20:33:07 +08:00
for (i in seq_along(x)) {
results[i] <- length(x[[i]])
}
results
```
There are three parts to a for loop:
2015-11-19 02:03:51 +08:00
1. The __results__: `results <- vector("integer", length(x))`.
This creates an integer vector the same length as the input. It's important
to enough space for all the results up front, otherwise you have to grow the
results vector at each iteration, which is very slow for large loops.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
1. The __sequence__: `i in seq_along(x)`. This determines what to loop over:
each run of the for loop will assign `i` to a different value from
`seq_along(x)`, shorthand for `1:length(x)`.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
1. The __body__: `results[i] <- length(x[[i]])`. This code is run repeatedly,
each time with a different value in `i`. The first iteration will run
`results[1] <- length(x[[1]])`, the second `results[2] <- length(x[[2]])`,
and so on.
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
This loop used a function you might not be familiar with: `seq_along()`. This is a safe version of the more familiar `1:length(l)`. There's one important difference in behaviour. If you have a zero-length vector, `seq_along()` does the right thing:
```{r}
y <- numeric(0)
seq_along(y)
1:length(y)
```
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
Figuring out the length of the elements of a list is a common operation, so it makes sense to turn it into a function so we can reuse it again and again:
2015-11-09 20:33:07 +08:00
```{r}
compute_length <- function(x) {
results <- vector("numeric", length(x))
for (i in seq_along(x)) {
results[i] <- length(x[[i]])
}
results
}
compute_length(x)
```
2015-11-19 02:03:51 +08:00
(And in fact base R has this already: it's called `lengths()`.)
Now imagine we want to compute the `mean()` of each element. How would our function change? What if we wanted to compute the `median()`? You could create variations of `compute_lengths()` like this:
2015-11-09 20:33:07 +08:00
```{r}
compute_mean <- function(x) {
results <- vector("numeric", length(x))
for (i in seq_along(x)) {
results[i] <- mean(x[[i]])
}
results
}
compute_mean(x)
compute_median <- function(x) {
results <- vector("numeric", length(x))
for (i in seq_along(x)) {
results[i] <- median(x[[i]])
}
results
}
compute_median(x)
```
2015-11-19 02:03:51 +08:00
But this is only two functions we might want to apply to every element of a list, and there's already lot of duplication. Most of the code is for-loop boilerplate and it's hard to see the one function (`length()`, `mean()`, or `median()`) that's actually important.
2015-11-09 20:33:07 +08:00
What would you do if you saw a set of functions like this:
```{r}
f1 <- function(x) abs(x - mean(x)) ^ 1
f2 <- function(x) abs(x - mean(x)) ^ 2
f3 <- function(x) abs(x - mean(x)) ^ 3
```
You'd notice that there's a lot of duplication, and extract it in to an additional argument:
```{r}
f <- function(x, i) abs(x - mean(x)) ^ i
```
2015-11-19 02:03:51 +08:00
You've reduce the chance of bugs (because you now have 1/3 less code), and made it easy to generalise to new situations. We can do exactly the same thing with `compute_length()`, `compute_median()` and `compute_mean()`:
2015-11-09 20:33:07 +08:00
```{r}
compute_summary <- function(x, f) {
results <- vector("numeric", length(x))
for (i in seq_along(x)) {
results[i] <- f(x[[i]])
}
results
}
compute_summary(x, mean)
```
2015-11-19 02:03:51 +08:00
Instead of hardcoding the summary function, we allow it to vary, by adding an addition argument that is a function. It can take a while to wrap your head around this, but it's very powerful technique. This is one of the reasons that R is known as a "functional" programming language.
2015-11-09 20:33:07 +08:00
2015-11-20 01:18:36 +08:00
### Exercises
1. Read the documentation for `apply()`. In the 2d case, what two for loops
does it generalise?
1. It's common to see for loops that don't preallocate the output and instead
increase the length of a vector at each step:
```{r}
results <- vector("integer", 0)
for (i in seq_along(x)) {
2015-11-21 03:31:32 +08:00
results <- c(results, lengths(x[[i]]))
2015-11-20 01:18:36 +08:00
}
results
```
How does this impact performance?
2015-11-19 02:03:51 +08:00
## The map functions
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
This pattern of looping over a list and doing something to each element is so common that the purrr package provides a family of functions to do it for you. Each function always returns the same type of output so there are six variations based on what sort of result you want:
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
* `map()`: a list.
* `map_lgl()`: a logical vector.
* `map_int()`: a integer vector.
* `map_dbl()`: a double vector.
* `map_chr()`: a character vector.
* `map_df()`: a data frame.
* `walk(): nothing (called exclusively for side effects).
If none of the specialised versions return exactly what you want, you can always use a `map()` because a list can contain any other object.
Each of these functions take a list as input, applies a function to each piece and then return a new vector that's the same length as the input. The following code uses purrr to do the same computations we did above:
2015-11-09 20:33:07 +08:00
```{r}
2015-11-09 22:58:33 +08:00
map_int(x, length)
map_dbl(x, mean)
2015-11-19 02:03:51 +08:00
map_dbl(x, median)
2015-11-09 20:33:07 +08:00
```
2015-11-19 02:03:51 +08:00
There are a few differences between `map_*()` and `compute_summary()`:
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
* They are implemented in C code. This means you can't easily understand their
implementation, but it reduces a little overhead so they run even faster
than for loops.
* The second argument, `.f,` the function to apply to each element can be
a formula, a character vector, or an integer vector. You'll learn about
those handy shortcuts in the next section.
* You can pass on additional arguments to `.f`:
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
```{r}
map_dbl(x, mean, trim = 0.5)
map_dbl(x, function(x) mean(x, trim = 0.5))
```
2015-11-09 20:33:07 +08:00
2015-11-19 02:03:51 +08:00
* They preserve names:
2015-11-09 22:58:33 +08:00
2015-11-19 02:03:51 +08:00
```{r}
z <- list(x = 1:3, y = 4:5)
map_int(z, length)
```
If you're familiar with the apply family of functions in base R, you might have noticed some similarities with the purrr functions:
* `lapply()` is basically identical to `map()`. There's no advantage to using
`map()` over `lapply()` except that it's consistent with all the other
functions in purrr.
* The base `sapply()` is wrapper around `lapply()` that automatically tries
to simplify the results. This is useful for interactive work but is
problematic in a function because you never know what sort of output
you'll get:
```{r}
df <- data.frame(
a = 1L,
b = 1.5,
y = Sys.time(),
z = ordered(1)
)
str(sapply(df[1:4], class))
str(sapply(df[1:2], class))
str(sapply(df[3:4], class))
```
* `vapply()` is a safe alternative to `sapply()` because you supply an additional
argument that defines the type. The only problem with `vapply()` is that
it's a lot of typing: `vapply(df, is.numeric, logical(1))` is equivalent to
`map_lgl(df, is.numeric)`. One advantage to `vapply()` over the map
functions is that it can also produce matrices.
2015-11-09 20:33:07 +08:00
2015-11-20 01:18:36 +08:00
### Exercises
1. How can you determine which columns in a data frame are factors?
(Hint: data frames are lists.)
1. What happens when you use the map functions on vectors that aren't lists?
What does `map(1:5, runif)` do? Why?
1. What does `map(-2:2, rnorm, n = 5)` do. Why?
2015-11-09 22:58:33 +08:00
## Pipelines
2015-11-21 03:31:32 +08:00
`map()` is particularly useful when constructing more complex transformations because it inputs and outputs a list. Since a list can contain any object type, `map()` is well suited for complex tasks with many intermediate steps.
2015-11-09 22:58:33 +08:00
TODO: find interesting dataset
2015-11-20 01:18:36 +08:00
For example, imagine you want to fit a linear model to each individual in a dataset. Let's start by working through the whole process on the complete dataset. It's always a good idea to start simple (with a single object), and figure out the basic workflow. Then you can generalise up to the harder problem of applying the same steps to multiple models.
2015-11-09 22:58:33 +08:00
You could start by creating a list where each element is a data frame for a different person:
```{r}
models <- mtcars %>%
split(.$cyl) %>%
map(function(df) lm(mpg ~ wt, data = df))
```
2015-11-21 03:31:32 +08:00
The syntax for creating an anonymous function in R is quite long so purrr provides a convenient shortcut: a one-sided formula.
2015-11-09 22:58:33 +08:00
```{r}
models <- mtcars %>%
split(.$cyl) %>%
map(~lm(mpg ~ wt, data = .))
```
2015-11-21 03:31:32 +08:00
Here I've used the pronoun `.`. You can also use `.x` and `.y` to refer to up to two arguments. If you want to create an function with more than two arguments, do it the regular way!
2015-11-09 22:58:33 +08:00
2015-11-21 03:31:32 +08:00
A common application of map functions is extracting a nested element. For example, to extract the R squared of a model, we need to first run `summary()` and then extract the component called "r.squared":
2015-11-09 22:58:33 +08:00
```{r}
models %>%
map(summary) %>%
map_dbl(~.$r.squared)
```
2015-11-21 03:31:32 +08:00
To make that easier, purrr provides a shortcut: you can use a character vector to select elements by name, or a numeric vector to select elements by position:
2015-11-09 22:58:33 +08:00
```{r}
models %>%
map(summary) %>%
map_dbl("r.squared")
```
### Navigating hierarchy
These techniques are useful in general when working with complex nested object. One way to get such an object is to create many models or other complex things in R. Other times you get a complex object because you're reading in hierarchical data from another source.
2015-11-21 03:31:32 +08:00
A common source of hierarchical data is JSON from a web API. I've previously downloaded a list of GitHub issues related to this book and saved it as `issues.json`. Now I'm going to load it with jsonlite. By default `fromJSON()` tries to be helpful and simplifies the structure a little. Here I'm going to show you how to do it by hand, so I set `simplifyVector = FALSE`:
2015-11-09 22:58:33 +08:00
```{r}
2015-11-21 03:31:32 +08:00
# From https://api.github.com/repos/hadley/r4ds/issues
issues <- jsonlite::fromJSON("issues.json", simplifyVector = FALSE)
```
2015-11-09 22:58:33 +08:00
2015-11-21 03:31:32 +08:00
There are eight issues, and each issue has a nested structure.
```{r}
2015-11-09 22:58:33 +08:00
length(issues)
str(issues[[1]])
```
2015-11-21 03:31:32 +08:00
To work with this sort of data, you typically want to turn it into a data frame by extracting the related vectors that you're most interested in.
```{r}
issues %>% map_int("id")
issues %>% map_lgl("locked")
issues %>% map_chr("state")
```
You can use the same technique to extract more deeply nested structure. For example, imagine you want to extract the name and id of the user. You could do that in two steps:
```{r}
users <- issues %>% map("user")
users %>% map_chr("login")
users %>% map_int("id")
```
Or by using a character vector, you can do it in one:
2015-11-09 22:58:33 +08:00
```{r}
issues %>% map_chr(c("user", "login"))
issues %>% map_int(c("user", "id"))
```
2015-11-21 03:31:32 +08:00
This is particularly useful when you want to dive deep into a nested data structure.
### Removing a level of hierarchy
As well as indexing deeply into hierarchy, it's sometimes useful to flatten it. That's the job of the flatten family of functions: `flatten()`, `flatten_lgl()`, `flatten_int()`, `flatten_dbl()`, and `flatten_chr()`.
Here we take a list of lists of double vectors, then flatten it to a list of double vectors, then to a double vector.
```{r}
x <- list(list(a = 1, b = 2), list(c = 3, d = 4))
x %>% str()
x %>% flatten() %>% str()
x %>% flatten() %>% flatten_dbl()
```
Graphically, that sequence of operations looks like:
`r bookdown::embed_png("diagrams/flatten.png", dpi = 220)`
2015-11-13 03:43:06 +08:00
### Predicates
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
Imagine we want to summarise each numeric column of a data frame. We could do it in two steps. First find the numeric columns in the data frame, and then summarise them.
2015-11-09 20:33:07 +08:00
```{r}
col_sum <- function(df, f) {
2015-11-13 03:43:06 +08:00
is_num <- df %>% map_lgl(is_numeric)
2015-11-09 20:33:07 +08:00
df[is_num] %>% map_dbl(f)
}
```
2015-11-21 03:31:32 +08:00
`is_numeric()` is a __predicate__: a function that returns a logical output. There are a number of of purrr functions designed to work specifically with predicate functions:
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
* `keep()` and `discard()` keeps/discards list elements where the predicate is
true.
* `head_while()` and `tail_while()` keep the first/last elements of a list until
you get the first element where the predicate is true.
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
* `some()` and `every()` determine if the predicate is true for any or all of
the elements.
* `detect()` and `detect_index()`
2015-11-09 20:33:07 +08:00
That allows us to simply the summary function to:
```{r}
col_sum <- function(df, f) {
df %>%
keep(is.numeric) %>%
map_dbl(f)
}
```
2015-11-13 03:43:06 +08:00
This is a nice example of the benefits of piping - we can more easily see the sequence of transformations done to the list. First we throw away non-numeric columns and then we apply the function `f` to each one.
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
### Built-in predicates
Purrr comes with a number of predicate functions built-in:
| | lgl | int | dbl | chr | list | null |
|------------------|-----|-----|-----|-----|------|------|
| `is_logical()` | x | | | | | |
| `is_integer()` | | x | | | | |
| `is_double()` | | | x | | | |
| `is_numeric()` | | x | x | | | |
| `is_character()` | | | | x | | |
| `is_atomic()` | x | x | x | x | | |
| `is_list()` | | | | | x | |
| `is_vector()` | x | x | x | x | x | |
| `is_null()` | | | | | | x |
Compared to the base R functions, they only inspect the type of object, not the attributes. This means they tend to be less suprising:
```{r}
is.atomic(NULL)
is_atomic(NULL)
is.vector(factor("a"))
is_vector(factor("a"))
```
Each predicate also comes with "scalar" and "bare" versions. The scalar version checks that the length is 1 and the bare version checks that the object is a bare vector with no S3 class.
```{r}
y <- factor(c("a", "b", "c"))
is_integer(y)
is_scalar_integer(y)
is_bare_integer(y)
```
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
### Exercises
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
1. Rewrite `map(x, function(df) lm(mpg ~ wt, data = df))` to eliminate the
anonymous function.
1. A possible base R equivalent of `col_sum` is:
```{r}
col_sum3 <- function(df, f) {
is_num <- sapply(df, is.numeric)
df_num <- df[, is_num]
sapply(df_num, f)
}
```
But it has a number of bugs as illustrated with the following inputs:
```{r, eval = FALSE}
df <- data.frame(z = c("a", "b", "c"), x = 1:3, y = 3:1)
# OK
col_sum3(df, mean)
# Has problems: don't always return numeric vector
col_sum3(df[1:2], mean)
col_sum3(df[1], mean)
col_sum3(df[0], mean)
```
What causes the bugs?
1. Carefully read the documentation of `is.vector()`. What does it actually
test for?
2015-11-09 22:58:33 +08:00
## Dealing with failure
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
When you do many operations on a list, sometimes one will fail. When this happens, you'll get an error message, and no output. This is annoying: why does one failure prevent you from accessing all the other successes? How do you ensure that one bad apple doesn't ruin the whole barrel?
In this section you'll learn how to deal this situation with a new function: `safely()`. `safely()` is an adverb: it takes a function and returns a modified function. In this case, the modified function returns a list with elements `result` (the original result) and `error` (the text of the error if it occured). For any given run, one will always be `NULL`.
2015-11-11 01:12:09 +08:00
2015-11-21 03:31:32 +08:00
(You might be familiar with the `try()` function in base R. It's similar, but because it sometimes returns the original result and it sometimes returns an error object it's more difficult to work with.)
2015-11-11 01:12:09 +08:00
Let's illustrate this with a simple example: `log()`:
```{r}
2015-11-20 01:18:36 +08:00
safe_log <- safely(log)
2015-11-11 01:12:09 +08:00
str(safe_log(10))
str(safe_log("a"))
```
2015-11-21 03:31:32 +08:00
When the function succeeds the `result` element contains the result and the error element is empty. When the function fails, the result element is empty and the error element contains the error.
2015-11-11 01:12:09 +08:00
This makes it natural to work with map:
```{r}
x <- list(1, 10, "a")
y <- x %>% map(safe_log)
str(y)
```
2015-11-21 03:31:32 +08:00
This would be easier to work with if we had two lists: one of all the errors and one of all the results. You already know how to extract those!
2015-11-09 20:33:07 +08:00
2015-11-11 01:12:09 +08:00
```{r}
2015-11-13 03:43:06 +08:00
result <- y %>% map("result")
error <- y %>% map("error")
2015-11-11 01:12:09 +08:00
```
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
It's up to you how to deal with the errors, but typically you'll either look at the values of `x` where `y` is an error or work with the values of y that are ok:
2015-11-11 01:12:09 +08:00
```{r}
2015-11-21 03:31:32 +08:00
is_ok <- error %>% map_lgl(is_null)
2015-11-13 03:43:06 +08:00
x[!is_ok]
2015-11-21 03:31:32 +08:00
result[is_ok] %>% flatten_dbl()
2015-11-13 03:43:06 +08:00
```
Other related functions:
2015-11-21 03:31:32 +08:00
* `possibly()`: if you don't care about the error message, and instead
just want a default value on failure.
```{r}
x <- list(1, 10, "a")
x %>% map_dbl(possibly(log, NA_real_))
```
* `quietly()`: does a similar job but for other outputs like printed
ouput, messages, and warnings.
```{r}
x <- list(1, -1)
x %>% map(quietly(log)) %>% str()
```
2015-11-13 03:43:06 +08:00
2015-11-21 03:31:32 +08:00
### Exercises
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
1. Challenge: read all the csv files in this directory. Which ones failed
and why?
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
```{r, eval = FALSE}
files <- dir("data", pattern = "\\.csv$")
files %>%
set_names(., basename(.)) %>%
map_df(readr::read_csv, .id = "filename") %>%
```
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
## Parallel maps
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
So far we've mapped along a single list. But often you have mutliple related lists that you need iterate along in parallel. That's the job of the `map2()` and `pmap()` functions. For example, imagine you want to simulate some random normals with different means. You know how to do that with `map()`:
2015-11-09 20:33:07 +08:00
```{r}
2015-11-09 22:58:33 +08:00
mu <- c(5, 10, -3)
mu %>% map(rnorm, n = 10)
2015-11-09 20:33:07 +08:00
```
2015-11-21 03:31:32 +08:00
What if you also want to vary the standard deviation? You need to iterate along a vector of means and a vector of standard deviations in parallel. That's a job for `map2()` which works with two parallel sets of inputs:
2015-11-09 22:58:33 +08:00
```{r}
sd <- c(1, 5, 10)
map2(mu, sd, rnorm, n = 10)
```
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
Note that arguments that vary for each call come before the function name, and arguments that are the same for every function call come afterwards.
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
Like `map()`, conceptually `map2()` is a wrapper around a for loop:
2015-11-09 20:33:07 +08:00
```{r}
map2 <- function(x, y, f, ...) {
out <- vector("list", length(x))
for (i in seq_along(x)) {
out[[i]] <- f(x[[i]], y[[i]], ...)
}
out
}
2015-11-09 22:58:33 +08:00
```
2015-11-21 03:31:32 +08:00
You could imagine `map3()`, `map4()`, `map5()`, `map6()` etc, but that would get tedious quickly. Instead, purrr provides `pmap()` which takes a list of arguments. You might use that if you wanted to vary the mean, standard deviation, and number of samples:
2015-11-09 22:58:33 +08:00
```{r}
2015-11-21 03:31:32 +08:00
n <- c(1, 3, 5)
pmap(list(n, mu, sd), rnorm)
2015-11-09 22:58:33 +08:00
```
2015-11-21 03:31:32 +08:00
However, instead of relying on position matching, it's better to name the arguments. This is more verbose, but you're less likely to make a mistake.
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
```{r}
2015-11-21 03:31:32 +08:00
pmap(list(mean = mu, sd = sd, n = n), rnorm)
2015-11-09 22:58:33 +08:00
```
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
Since the arguments are all the same length, it makes sense to store them in a dataframe:
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
```{r}
params <- dplyr::data_frame(mean = mu, sd = sd, n = n)
2015-11-21 03:31:32 +08:00
params$result <- params %>% pmap(rnorm)
params
2015-11-09 22:58:33 +08:00
```
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
As soon as you get beyond simple examples, I think using data frames + `pmap()` is the way to go because the data frame ensures that each column as a name, and is the same length as all the other columns. This makes your code easier to understand once you've grasped this powerful pattern.
2015-11-09 20:33:07 +08:00
2015-11-21 03:31:32 +08:00
There's one more step up in complexity - as well as varying the arguments to the function you might also vary the function itself:
2015-11-13 03:43:06 +08:00
```{r}
f <- c("runif", "rnorm", "rpois")
param <- list(
list(min = -1, max = 1),
list(sd = 5),
list(lambda = 10)
)
```
To handle this case, you can use `invoke_map()`:
```{r}
invoke_map(f, param, n = 5)
```
The first argument is a list of functions or character vector of function names, the second argument is a list of lists giving the arguments that vary for each function. The subsequent arguments are passed on to every function.
You can use `dplyr::frame_data()` to create these matching pairs a little easier:
```{r}
sim <- dplyr::frame_data(
~f, ~params,
"runif", list(min = -1, max = -1),
"rnorm", list(sd = 5),
"rpois", list(lambda = 10)
)
sim %>% dplyr::mutate(
samples = invoke_map(f, params, n = 10)
)
```
2015-11-21 03:31:32 +08:00
## A case study: modelling
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
A natural application of `map2()` is handling test-training pairs when doing model evaluation. This is an important modelling technique: you should never evaluate a model on the same data it was fit to because it's going to make you overconfident. Instead, it's better to divide the data up and use one piece to fit the model and the other piece to evaluate it. A popular technique for this is called k-fold cross validation. You randomly hold out x% of the data and fit the model to the rest. You need to repeat this a few times because of random variation.
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
Let's start by writing a function that partitions a dataset into test and training:
2015-11-09 20:33:07 +08:00
```{r}
2015-11-09 22:58:33 +08:00
partition <- function(df, p) {
n <- nrow(df)
groups <- rep(c(TRUE, FALSE), n * c(p, 1 - p))
sample(groups)
}
partition(mtcars, 0.1)
2015-11-09 20:33:07 +08:00
```
2015-11-09 22:58:33 +08:00
We'll generate 20 random test-training splits, and then create lists of test-training datasets:
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
```{r}
partitions <- rerun(200, partition(mtcars, 0.25))
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
tst <- partitions %>% map(~mtcars[.x, , drop = FALSE])
trn <- partitions %>% map(~mtcars[!.x, , drop = FALSE])
```
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
Then fit the models to each training dataset:
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
```{r}
mod <- trn %>% map(~lm(mpg ~ wt, data = .))
```
2015-11-09 20:33:07 +08:00
2015-11-12 01:31:15 +08:00
If we wanted, we could extract the coefficients using broom, and make a single data frame with `map_df()` and then visualise the distributions with ggplot2:
2015-11-09 20:33:07 +08:00
2015-11-09 22:58:33 +08:00
```{r}
coef <- mod %>%
2015-11-19 02:03:51 +08:00
map_df(broom::tidy, .id = "i")
2015-11-09 22:58:33 +08:00
coef
library(ggplot2)
ggplot(coef, aes(estimate)) +
geom_histogram(bins = 10) +
facet_wrap(~term, scales = "free_x")
```
But we're most interested in the quality of the models, so we make predictions for each test data set and compute the mean squared distance between predicted and actual:
2015-11-09 20:33:07 +08:00
```{r}
2015-11-09 22:58:33 +08:00
pred <- map2(mod, tst, predict)
actl <- map(tst, "mpg")
msd <- function(x, y) sqrt(mean((x - y) ^ 2))
2015-11-19 02:03:51 +08:00
mse <- map2_dbl(pred, actl, msd)
2015-11-09 22:58:33 +08:00
mean(mse)
mod <- lm(mpg ~ wt, data = mtcars)
base_mse <- msd(mtcars$mpg, predict(mod))
base_mse
ggplot(, aes(mse)) +
geom_histogram(binwidth = 0.25) +
geom_vline(xintercept = base_mse, colour = "red")
2015-11-09 20:33:07 +08:00
```
2015-11-21 03:31:32 +08:00
## Tidy lists
2015-11-09 22:58:33 +08:00
2015-11-09 20:33:07 +08:00
I don't know know how to put this stuff in words yet, but I know it
when I see it, and I have a good intuition for what operation you
should do at each step. This is where I was 5 years for tidy data - I
can do it, but it's so internalised that I don't know what I'm doing
and I don't know how to teach it to other people.
Two key tools:
* flatten(), flatmap(), and lmap(): sometimes list doesn't have quite
the right grouping level and you need to change
2015-11-19 02:03:51 +08:00
* transpose(): sometimes list is "inside out"
2015-11-09 20:33:07 +08:00
Challenges: various weird json files?
2015-11-21 03:31:32 +08:00
### Data frames
Why you should store related vectors (even if they're lists!) in a
data frame. Need example that has some covariates so you can (e.g.)
select all models for females, or under 30s, ...