No longer need out.width for diagrams

weirubin · Apr 22, 2016 · e36a6cc · e36a6cc
1 parent d43119a
commit e36a6cc
Show file tree

Hide file tree

Showing 5 changed files with 17 additions and 16 deletions.
diff --git a/DESCRIPTION b/DESCRIPTION
@@ -39,4  39,5 @@ Remotes:
   hadley/stringr,
   hadley/ggplot2,
   hadley/nycflights13,
   yihui/knitr,
   rstudio/bookdown
diff --git a/hierarchy.Rmd b/hierarchy.Rmd
@@ -101,7  101,7 @@ x %>% transpose() %>% str()
 
 Graphically, this looks like:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/lists-transpose.png")
 ```
 

diff --git a/iteration.Rmd b/iteration.Rmd
@@ -727,7  727,7 @@ map2(mu, sigma, rnorm, n = 5) %>% str()
 
 `map2()` generates this series of function calls:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/lists-map2.png")
 ```
 
@@ -755,7  755,7 @@ args1 %>% pmap(rnorm) %>% str()
 
 That looks like:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/lists-pmap-unnamed.png")
 ```
 
@@ -768,7  768,7 @@ args2 %>% pmap(rnorm) %>% str()
 
 That generates longer, but safer, calls:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/lists-pmap-named.png")
 ```
 

diff --git a/relational-data.Rmd b/relational-data.Rmd
@@ -54,7  54,7 @@ You can use the nycflights13 package to learn about relational data. nycflights1
 
 One way to show the relationships between the different tables is with a drawing:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/relational-nycflights.png")
 ```
 
@@ -176,7  176,7 @@ The following sections explain, in detail, how mutating joins work. You'll start
 
 To help you learn how joins work, I'm going to represent data frames visually:
 
-```{r, echo = FALSE, out.width = "25%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-setup.png")
 ```
 ```{r}
@@ -188,23  188,23 @@ The coloured column represents the "key" variable: these are used to match the r
 
 A join is a way of connecting each row in `x` to zero, one, or more rows in `y`. The following diagram shows each potential match as an intersection of a pair of lines.
 
-```{r, echo = FALSE, out.width = "35%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-setup2.png")
 ```
 
 (If you look closely, you might notice that we've switched the order of the keys and values in `x`. This is to emphasise that joins match based on the key variable; value variable is just carried along for the ride.)
 
 In an actual join, matches will be indicated with dots. The colour of the dots match the colour of the keys to remind that that's what important. Then the number of dots = the number of matches = the number of rows in the output.
 
-```{r, echo = FALSE, out.width = "70%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-inner.png")
 ```
 
 ### Inner join {#inner-join}
 
 The simplest type of join is the __inner join__. An inner join matches pairs of observations whenever their keys are equal:
 
-```{r, echo = FALSE, out.width = "70%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-inner.png")
 ```
 
@@ -230,7  230,7 @@ These joins work by adding an additional "virtual" observation to each table. Th
 
 Graphically, that looks like:
 
-```{r, echo = FALSE, out.width = "75%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-outer.png")
 ```
 
@@ -252,7  252,7 @@ So far all the diagrams have assumed that the keys are unique. But that's not al
     add in additional information as there is typically a one-to-many
     relationship.
 
-    ```{r, echo = FALSE, out.width = "75%"}
     ```{r, echo = FALSE}
     knitr::include_graphics("diagrams/join-one-to-many.png")
     ```
 
@@ -270,7  270,7 @@ So far all the diagrams have assumed that the keys are unique. But that's not al
     neither table do the keys uniquely identify an observation. When you join
     duplicated keys, you get all possible combinations, the Cartesian product:
 
-    ```{r, echo = FALSE, out.width = "75%"}
     ```{r, echo = FALSE}
     knitr::include_graphics("diagrams/join-many-to-many.png")
     ```
 
@@ -416,19  416,19 @@ flights %>% semi_join(top_dest)
 
 Graphically, a semi-join looks like this:
 
-```{r, echo = FALSE, out.width = "50%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-semi.png")
 ```
 
 Only the existence of a match is important; it doesn't matter which observation is matched. This means that filtering joins never duplicate rows like mutating joins do:
 
-```{r, echo = FALSE, out.width = "50%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-semi-many.png")
 ```
 
 The inverse of a semi-join is an anti-join. An anti-join keeps the rows that _don't_ have a match:
 
-```{r, echo = FALSE, out.width = "50%"}
 ```{r, echo = FALSE}
 knitr::include_graphics("diagrams/join-anti.png")
 ```
 

diff --git a/transform.Rmd b/transform.Rmd
@@ -214,7  214,7 @@ filter(flights, month %in% c(11, 12))
 
 The following figure shows the complete set of boolean operations:
 
-```{r bool-ops, echo = FALSE, fig.cap = "Complete set of boolean operations",  out.width = "75%"}
 ```{r bool-ops, echo = FALSE, fig.cap = "Complete set of boolean operations"}
 knitr::include_graphics("diagrams/transform-logical.png")
 ```