r4ds/data-tidy.Rmd

# Data tidying {#data-tidy}

## Introduction

> "Happy families are all alike; every unhappy family is unhappy in its own way." --- Leo Tolstoy

> "Tidy datasets are all alike, but every messy dataset is messy in its own way." --- Hadley Wickham

In this chapter, you will learn a consistent way to organize your data in R using a system called **tidy data**.
Getting your data into this format requires some work up front, but that work pays off in the long term.
Once you have tidy data and the tidy tools provided by packages in the tidyverse, you will spend much less time munging data from one representation to another, allowing you to spend more time on the data questions you care about.

This chapter will give you a practical introduction to tidy data and the accompanying tools in the **tidyr** package.
If you'd like to learn more about the underlying theory, you might enjoy the *Tidy Data* paper published in the Journal of Statistical Software, <http://www.jstatsoft.org/v59/i10/paper>.

### Prerequisites

In this chapter we'll focus on tidyr, a package that provides a bunch of tools to help tidy up your messy datasets.
tidyr is a member of the core tidyverse.

```{r setup, message = FALSE}
library(tidyverse)
```

From this chapter on, we'll suppress the loading message from `library(tidyverse)`.

## Tidy data

You can represent the same underlying data in multiple ways.
The example below shows the same data organised in four different ways.
Each dataset shows the same values of four variables *country*, *year*, *population*, and *cases*, but each dataset organizes the values in a different way.

```{r}
table1
table2
table3

# Spread across two tibbles
table4a # cases
table4b # population
```

These are all representations of the same underlying data, but they are not equally easy to use.
One of them, `table1`, will be much easier to work with inside the tidyverse because it's tidy.
There are three interrelated rules that make a dataset tidy:

1.  Each variable is a column; each column is a variable.
2.  Each observation is row; each row is an observation.
3.  Each value is a cell; each cell is a single value.

Figure \@ref(fig:tidy-structure) shows the rules visually.

```{r tidy-structure, echo = FALSE, out.width = "100%"}
#| fig.cap: > 
#|   Following three rules makes a dataset tidy: variables are columns,
#|   observations are rows, and values are cells.
#| fig.alt: > 
#|   Three panels, each representing a tidy data frame. The first panel
#|   shows that each variable is column. The second panel shows that each
#|   observation is a row. The third panel shows that each value is
#|   a cell.
knitr::include_graphics("images/tidy-1.png")
```

Why ensure that your data is tidy?
There are two main advantages:

1.  There's a general advantage to picking one consistent way of storing data.
    If you have a consistent data structure, it's easier to learn the tools that work with it because they have an underlying uniformity.

2.  There's a specific advantage to placing variables in columns because it allows R's vectorised nature to shine.
    As you learned in Sections \@ref(mutate) and \@ref(summarise), most built-in R functions work with vectors of values.
    That makes transforming tidy data feel particularly natural.

dplyr, ggplot2, and all the other packages in the tidyverse are designed to work with tidy data.
Here are a couple of small examples showing how you might work with `table1`.

```{r fig.width = 5}
#| fig.alt: >
#|   This figure shows the numbers of cases in 1999 and 2000 for 
#|   Afghanistan, Brazil, and China, with year on the x-axis and number 
#|   of cases on the y-axis. Each point on the plot represents the number 
#|   of cases in a given country in a given year. The points for each
#|   country are differentiated from others by color and shape and connected
#|   with a line, resulting in three, non-parallel, non-intersecting lines.
#|   The numbers of cases in China are highest for both 1999 and 2000, with
#|   values above 200,000 for both years. The number of cases in Brazil is
#|   approximately 40,000 in 1999 and approximately 75,000 in 2000. The
#|   numbers of cases in Afghanistan are lowest for both 1999 and 2000, with
#|   values that appear to be very close to 0 on this scale.

# Compute rate per 10,000
table1 |>
  mutate(
    rate = cases / population * 10000
  )

# Compute cases per year
table1 |>
  count(year, wt = cases)

# Visualise changes over time
ggplot(table1, aes(year, cases)) +
  geom_line(aes(group = country), colour = "grey50") +
  geom_point(aes(colour = country, shape = country)) +
  scale_x_continuous(breaks = c(1999, 2000))
```

### Exercises

1.  Using prose, describe how the variables and observations are organised in each of the sample tables.

2.  Compute the `rate` for `table2`, and `table4a` + `table4b`.
    You will need to perform four operations:

    a.  Extract the number of TB cases per country per year.
    b.  Extract the matching population per country per year.
    c.  Divide cases by population, and multiply by 10000.
    d.  Store back in the appropriate place.

    Which representation is easiest to work with?
    Which is hardest?
    Why?

3.  Recreate the plot showing change in cases over time using `table2` instead of `table1`.
    What do you need to do first?

## Pivoting

The principles of tidy data might seem so obvious that you wonder if you'll ever encounter a dataset that isn't tidy.
Unfortunately, however, most real data is untidy.
There are two main reasons:

1.  Data is often organised to facilitate some goal other than analysis.
    For example, it's common for data to be structure to make recording it easy.

2.  Most people aren't familiar with the principles of tidy data, and it's hard to derive them yourself unless you spend a *lot* of time working with data.

This means that most real analyses will require at least a little tidying.
You'll begin by figuring out what the underlying variables and observations are.
Sometimes this is easy; other times you'll need to consult with the people who originally generated the data.
Next, you'll **pivot** your data into a tidy form, with variables in the columns and observations in the rows.

tidyr provides two functions for pivoting data: `pivot_longer()`, which makes datasets **longer** by increasing rows and reducing columns, and `pivot_wider()` which makes datasets **wider** by increasing columns and reducing rows.
`pivot_longer()` is very useful for tidying data; `pivot_wider()` is more useful for making non-tidy data (we'll come back to this in Section \@ref(non-tidy-data)), but is occasionally also needed for tidying..

The following sections work through the use of `pivot_longer()` and `pivot_wider()` to tackle a wide range of realistic datasets.
These examples are drawn from `vignette("pivot", package = "tidyr")` which includes more variations and more challenging problems.

### Data in column names {#billboard}

The `billboard` dataset records the billboard rank of songs in the year 2000:

```{r}
billboard
```

In this dataset, the observation is a song.
We have data about song and how it has performed over time.
The first three columns, `artist`, `track`, and `date.entered`, are variables.
Then we have 76 columns (`wk1`-`wk76`) used to describe the rank of the song in each week.
Here the column names one variable (the `week`) and the cell values are another (the `rank`).

To tidy this data we need to use `pivot_longer()`.
There are three key arguments:

-   `cols` specifies which which columns need to be pivoted (the columns that aren't variables) using the same syntax as `select()`. In this case, we could say `!c(artist, track, date.entered)` or `starts_with("wk")`
-   `names_to` names of the variable stored in the column names.
-   `values_to` names the variable stored in the cell values.

This gives the following call:

```{r}
billboard |> 
  pivot_longer(
    cols = starts_with("wk"), 
    names_to = "week", 
    values_to = "rank",
  )
```

What happens if a song is in the top 100 for less than 76 weeks?
You can that 2 Pacs "Baby Don't Cry" was only in the top100 for 7 weeks, and all the remaining rows are filled in with missing values.
These `NA`s don't really represent unknown observations; they're force to exist by the structure of the dataset.
We can ask `pivot_longer` to get rid of the by setting `values_drop_na = TRUE`:

```{r}
billboard |> 
  pivot_longer(
    cols = starts_with("wk"), 
    names_to = "week", 
    values_to = "rank",
    values_drop_na = TRUE
  )
```

You might also wonder what happens if a song is in the top 100 for more than 76 weeks?
We can't tell from this data, but you might guess that additional columns `wk77`, `wk78`, ... would be added to the dataset.

This data is now tidy, but we could make future computation a bit easier by converting `week` into a number.
We do this by using `mutate()` + `parse_number()`.
You'll learn more about `parse_number()` and friends in Chapter \@ref(data-import).

```{r}
billboard_tidy <- billboard |> 
  pivot_longer(
    cols = starts_with("wk"), 
    names_to = "week", 
    values_to = "rank",
    values_drop_na = TRUE
  ) |> 
  mutate(week = parse_number(week))
billboard_tidy
```

Now we're in a good position to look at the typical course of a song's rank by drawing a plot.

```{r}
#| fig.alt: >
#|   A line plot with week on the x-axis and rank on the y-axis, where
#|   each line represents a song. Most songs appear to start at a high rank,
#|   rapidly accelerate to a low rank, and then decay again. There are
#|   suprisingly few tracks in the region when week is >20 and rank is
#|   >50.
billboard_tidy |> 
  ggplot(aes(week, rank, group = track)) + 
  geom_line(alpha = 1/3) + 
  scale_y_reverse()
```

### Many variables in column names

A more challenging situation occurs when you have multiple variables crammed into the column names.
For example, take this minor variation on the `who` dataset:

```{r}
who2 <- who |> 
  rename_with(~ str_remove(.x, "new_?")) |> 
  rename_with(~ str_replace(.x, "([mf])", "\\1_")) |> 
  select(!starts_with("iso"))
who2
```

I've used regular expressions to make the problem a little simpler; you'll learn how they work in Chapter \@ref(regular-expressions).

This dataset records information about tuberculosis data collected by the WHO.
There are two columns that are easy to interpret: `country` and `year`.
They are followed by 56 column like `sp_m_014`, `ep_m_4554`, and `rel_m_3544`.
If you stare at these column for long enough, you'll notice there's a pattern.
Each column name is made up of three pieces separated by `_`.
The first piece, `sp`/`rel`/`ep`, describes the method used for the `diagnosis`, the second piece, `m`/`f` is the `gender`, and the third piece, `014`/`1524`/`2535`/`3544`/`4554`/`65` is the `age` range.

So in this case we have six variables: two variables are already columns, three variables are contained in the column name, and one variable is in the cell name.
This requires two changes to our call to `pivot_longer()`: `names_to` gets a vector of column names and `names_sep` describes how to split the variable name up into pieces:

```{r}
who2 |> 
  pivot_longer(
    cols = !(country:year),
    names_to = c("diagnosis", "gender", "age"), 
    names_sep = "_",
    values_to = "count"
  )
```

An alternative to `names_sep` is `names_pattern`, which you can use to extract variables from more complicated naming scenarios, once you've learned about regular expressions in Chapter \@ref(regular-expressions).

### Data and variable names in the column headers

The next step up in complexity is when the column names include a mix of variable values and variable names.
For example, take this dataset adapted from the [data.table vignette](https://CRAN.R-project.org/package=data.table/vignettes/datatable-reshape.html).
It contains data about five families, with the names and dates of birth of up to two children:

```{r}
family <- tribble(
  ~family,  ~dob_child1,  ~dob_child2, ~name_child1, ~name_child2,
        1, "1998-11-26", "2000-01-29",      "Susan",       "Jose",
        2, "1996-06-22",           NA,       "Mark",           NA,
        3, "2002-07-11", "2004-04-05",        "Sam",       "Seth",
        4, "2004-10-10", "2009-08-27",      "Craig",       "Khai",
        5, "2000-12-05", "2005-02-28",     "Parker",     "Gracie",
)
family <- family |> 
  mutate(across(starts_with("dob"), parse_date))
family
```

The new challenge in this dataset is that the column names contain both the name of variable (`dob`, `name)` and the value of a variable (`child1`, `child2`).
We again we need to supply a vector to `names_to` but this time we use the special `".value"`[^data-tidy-1] to indicate that first component of the column name is in fact a variable name.

[^data-tidy-1]: Calling this `.value` instead of `.variable` seems confusing so I think we'll change it: <https://github.com/tidyverse/tidyr/issues/1326>

```{r}
family |> 
  pivot_longer(
    cols = !family, 
    names_to = c(".value", "child"), 
    names_sep = "_", 
    values_drop_na = TRUE
  ) |> 
  mutate(child = parse_number(child))
```

We again use `values_drop_na = TRUE`, since the shape of the input forces the creation of explicit missing variables (e.g. for families with only one child), and `parse_number()` to convert (e.g.) `child1` into 1.

### Tidy census

So far we've used `pivot_longer()` to solves the common class of problems where values have ended up in column names.
Next we'll pivot (HA HA) to `pivot_wider()`, which helps when one observation is spread across multiple rows.
This seems to be a much less common problem in practice, but it's good to know about in case you hit it.

For example, take the `us_rent_income` dataset, which contains information about median income and rent for each state in the US for 2017 (from the American Community Survey, retrieved with the [tidycensus](https://walker-data.com/tidycensus/) package).

```{r}
us_rent_income
```

Here an observation is a state, and I think there are four variables.
`GEOID` and `NAME`, which identify the state and are already columns.
The `estimate` and `moe` (margin of error) for each of `rent` and `income`, i.e. `income_estimate`, `income_moe`, `rent_estimate`, `rent_moe`.

We can get most of the way there with a simple call to `pivot_wider()`:

```{r}
us_rent_income |> 
  pivot_wider(
    names_from = variable, 
    values_from = c(estimate, moe)
  )
```

However, there are two problems:

-   We want (e.g.) `income_estimate` not `estimate_income`
-   We want `_estimate` then `_moe` for each variable, not all the estimates then all the margins of error.

Fixing these problems requires more tweaking of the call to `pivot_wider()`.
The details aren't too important here but we can fix the renaming problems by providing a custom glue specification for creating the variable names, and have the variable names vary slowest rather than default of fastest:

```{r}
us_rent_income |> 
  pivot_wider(
    names_from = variable, 
    values_from = c(estimate, moe),
    names_glue = "{variable}_{.value}",
    names_vary = "slowest"
  )
```

Both `pivot_longer()` and `pivot_wider()` have many more capabilities that we get into in this work.
Once you're comfortable with the basics, we encourage to learn more by reading the documentation for the functions and the vignettes included in the tidyr package.

We'll see a couple more examples where `pivot_wider()` is useful in the next section where we work through some challenges that require both `pivot_longer()` and `pivot_wider()`.

## Case studies

Some problems can't be solved by pivoting in a single direction.
The two examples in this section show how you might combine both `pivot_longer()` and `pivot_wider()` to solve more complex problems.

### World bank

`world_bank_pop` contains data from the World Bank about population per country from 2000 to 2018.

```{r}
world_bank_pop
```

Our goal is to produce a tidy dataset where each variable is in a column, but I don't know exactly what variables exist yet, so I'm not sure what I'll need to do.
Luckily, there's one obvious problem to start with: year, which is clearly a variable, is spread across multiple columns.
I'll fix this with `pivot_longer()`:

```{r}
pop2 <- world_bank_pop |> 
  pivot_longer(
    cols = `2000`:`2017`, 
    names_to = "year", 
    values_to = "value"
  ) |> 
  mutate(year = parse_number(year))
pop2
```

Next we need to consider the `indicator` variable.
I use `count()` to see all possible values:

```{r}
pop2 |> 
  count(indicator)
```

There are only four values, and they have a consistent structure.
I then dig a little digging discovered that:

-   `SP.POP.GROW` is population growth,
-   `SP.POP.TOTL` is total population,
-   `SP.URB.GROW` is population growth in urban areas,
-   `SP.POP.TOTL` is total population in urban areas.

To me, this feels like it could be broken down into three variables:

-   `GROW`: population growth
-   `TOTL`: total population
-   `area`: whether the statistics apply to the complete country or just urban areas.

So I'll first separate indicator into these pieces:

```{r}
pop3 <- pop2 |> 
  separate(indicator, c(NA, "area", "variable"))
pop3
```

(You'll learn more about this function in Chapter \@ref(strings).)

And then complete the tidying by pivoting `variable` and `value` to make `TOTL` and `GROW` columns:

```{r}
pop3 |> 
  pivot_wider(
    names_from = variable, 
    values_from = value
  )
```

### Multi-choice

The final example shows a dataset inspired by [Maxime Wack](https://github.com/tidyverse/tidyr/issues/384), which requires us to deal with a common, but annoying, way of recording multiple choice data.
Often you will get such data as follows:

```{r}
multi <- tribble(
  ~id, ~choice1, ~choice2, ~choice3,
    1,      "A",      "B",      "C",
    2,      "B",      "C",       NA,
    3,      "D",       NA,       NA,
    4,      "B",      "D",       NA,
)
```

This represents the results of four surveys: person 1 selected A, B, and C; person 2 selected B and C; person 3 selected D; and person 4 selected B and D.

The current structure is not very useful because it's hard to (e.g.) find all people who chose B, and it would be more useful to have columns, A, B, C, and D.
To get to this form, we'll need two steps.
First, you make the data longer, eliminating the explicit `NA`s with `values_drop_na`, and adding a column to indicate that this response was chosen:

```{r}
multi2 <- multi |>  
  pivot_longer(
    cols = !id, 
    values_drop_na = TRUE
  ) |> 
  mutate(selected = TRUE)
multi2
```

Then you make the data wider, filling in the missing observations with `FALSE`:

```{r}
multi2 |> 
  mutate(selected = TRUE) |> 
  pivot_wider(
    id_cols = id,
    names_from = value, 
    values_from = selected, 
    values_fill = FALSE
  )
```

## Non-tidy data

Before we continue on to other topics, it's worth talking briefly about non-tidy data.
Earlier in the chapter, I used the pejorative term "messy" to refer to non-tidy data.
That's an oversimplification: there are lots of useful and well-founded data structures that are not tidy data.
There are three main reasons to use other data structures:

-   Alternative representations may have substantial performance or space advantages.

-   A specific field may have evolved its own conventions for storing data that are quite different to the conventions of tidy data.

-   You want to create a table for presentation.

Either of these reasons means you'll need something other than a tibble (or data frame).
If your data does fit naturally into a rectangular structure composed of observations and variables, I think tidy data should be your default choice.
But there are good reasons to use other structures; tidy data is not the only way.

For example, take the tidy `fish_encounters` dataset, which describes when fish swimming down a river are detected by automatic monitoring stations:

```{r}
fish_encounters
```

Many tools used to analyse this data need it in a non-tidy form where each station is a column.
`pivot_wider()` makes it easier to get our tidy dataset into this form:

```{r}
fish_encounters |> 
  pivot_wider(
    names_from = station, 
    values_from = seen,
    values_fill = 0
  )
```

This dataset only records when a fish was detected by the station - it doesn't record when it wasn't detected (this is common with this type of data).
That means the output data is filled with `NA`s.
However, in this case we know that the absence of a record means that the fish was not `seen`, so we can ask `pivot_wider()` to fill these missing values in with zeros:

```{r}
fish_encounters |> 
  pivot_wider(
    names_from = station, 
    values_from = seen,
    values_fill = 0
  )
```

If you'd like to learn more about non-tidy data, I'd highly recommend this thoughtful blog post by Jeff Leek: <https://simplystatistics.org/posts/2016-02-17-non-tidy-data>.