Reshaping Data with tidyr
This chapter describes how you can use the tidyr (“tidy-er”) package to effectively transform your data into an appropriate shape for analysis and visualization.
This chapter describes how you can use the tidyr (“tidy-er”) package to effectively transform your data into an appropriate shape for analysis and visualization.
Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTICLE.
* See informit.com/terms
This chapter is from the book
This chapter is from the book
This chapter is from the book
One of the most common data wrangling challenges is adjusting how exactly row and columns are used to represent your data. Structuring (or restructuring) data frames to have the desired shape can be the most difficult part of creating a visualization, running a statistical model, or implementing a machine learning algorithm.
This chapter describes how you can use the tidyr (“tidy-er”) package to effectively transform your data into an appropriate shape for analysis and visualization.
12.1 What Is “Tidy” Data?
When wrangling data into a data frame for your analysis, you need to decide on the desired structure of that data frame. You need to determine what each row and column will represent, so that you can consistently and clearly manipulate that data (e.g., you know what you will be selecting and what you will be filtering). The tidyr package is used to structure and work with data fames that follow three principles of tidy data (as described by the package’s documentation1):
Each variable is in a column.
Each observation is a row.
Each value is a cell.
Indeed, these principles lead to the data structuring described in Chapter 9: rows represent observations, and columns represent features of that data.
However, asking different questions of a data set may involve different interpretations of what constitutes an “observation.” For example, Section 11.6 described working with the flights data set from the nycflights13 package, in which each observation is a flight. However, the analysis made comparisons between airlines, airports, and months. Each question worked with a different unit of analysis, implying a different data structure (e.g., what should be represented by each row). While the example somewhat changed the nature of these rows by grouping and joining different data sets, having a more specific data structure where each row represented a specific unit of analysis (e.g., an airline or a month) may have made much of the wrangling and analysis more straightforward.
To use multiple different definitions of an “observation” when investigating your data, you will need to create multiple representations (i.e., data frames) of the same data set—each with its own configuration of rows and columns.
To demonstrate how you may need to adjust what each observation represents, consider the (fabricated) data set of music concert prices shown in Table 12.1. In this table, each observation (row) represents a city, with each city having features (columns) of the ticket price for a specific band.
Table 12.1 A “wide” data set of concert ticket price in different cities. Each observation (i.e., unit of analysis) is a city, and each feature is the concert ticket price for a given band.
city |
greensky_bluegrass |
trampled_by_turtles |
billy_strings |
fruition |
Seattle |
40 |
30 |
15 |
30 |
Portland |
40 |
20 |
25 |
50 |
Denver |
20 |
40 |
25 |
40 |
Minneapolis |
30 |
100 |
15 |
20 |
But consider if you wanted to analyze the ticket price across all concerts. You could not do this easily with the data in its current form, since the data is organized by city (not by concert)! You would prefer instead that all of the prices were listed in a single column, as a feature of a row representing a single concert (a city-and-band combination), as in Table 12.2.
Table 12.2 A “long” data set of concert ticket price by city and band. Each observation (i.e., unit of analysis) is a city–band combination, and each has a single feature that is the ticket price.
city |
band |
price |
Seattle |
greensky_bluegrass |
40 |
Portland |
greensky_bluegrass |
40 |
Denver |
greensky_bluegrass |
20 |
Minneapolis |
greensky_bluegrass |
30 |
Seattle |
trampled_by_turtles |
30 |
Portland |
trampled_by_turtles |
20 |
Denver |
trampled_by_turtles |
40 |
Minneapolis |
trampled_by_turtles |
100 |
Seattle |
billy_strings |
15 |
Portland |
billy_strings |
25 |
Denver |
billy_strings |
25 |
Minneapolis |
billy_strings |
15 |
Seattle |
fruition |
30 |
Portland |
fruition |
50 |
Denver |
fruition |
40 |
Minneapolis |
fruition |
20 |
Both Table 12.1 and Table 12.2 represent the same set of data—they both have prices for 16 different concerts. But by representing that data in terms of different observations, they may better support different analyses. These data tables are said to be in a different orientation: the price data in Table 12.1 is often referred to being in wide format (because it is spread wide across multiple columns), while the price data in Table 12.2 is in long format (because it is in one long column). Note that the long format table includes some duplicated data (the names of the cities and bands are repeated), which is part of why the data might instead be stored in wide format in the first place!