Fix typos (#950)
This commit is contained in:
parent
8efc22598b
commit
712907fc75
|
@ -498,7 +498,7 @@ readr contains a challenging CSV that illustrates both of these problems:
|
|||
challenge <- read_csv(readr_example("challenge.csv"))
|
||||
```
|
||||
|
||||
(Note the use of `readr_example()` which finds the path to one of the files included with the package)
|
||||
(Note the use of `readr_example()` which finds the path to one of the files included with the package.)
|
||||
|
||||
There are two printed outputs: the column specification generated by looking at the first 1000 rows, and the first five parsing failures.
|
||||
It's always a good idea to explicitly pull out the `problems()`, so you can explore them in more depth:
|
||||
|
|
|
@ -309,7 +309,7 @@ One way to add additional variables is with aesthetics.
|
|||
Another way, particularly useful for categorical variables, is to split your plot into **facets**, subplots that each display one subset of the data.
|
||||
|
||||
To facet your plot by a single variable, use `facet_wrap()`.
|
||||
The first argument of `facet_wrap()` is a formula, which you create with `~` followed by a variable name (here "formula" is the bane if a data structure in R, not a synonym for "equation").
|
||||
The first argument of `facet_wrap()` is a formula, which you create with `~` followed by a variable name (here, "formula" is the bane if a data structure in R, not a synonym for "equation").
|
||||
The variable that you pass to `facet_wrap()` should be discrete.
|
||||
|
||||
```{r, fig.alt = "Scatterplot of highway fuel efficiency versus engine size of cars in ggplot2::mpg, faceted by class, with facets spanning two rows."}
|
||||
|
|
|
@ -564,7 +564,7 @@ Examples include "America/New_York", "Europe/Paris", and "Pacific/Auckland".
|
|||
You might wonder why the time zone uses a city, when typically you think of time zones as associated with a country or region within a country.
|
||||
This is because the IANA database has to record decades worth of time zone rules.
|
||||
In the course of decades, countries change names (or break apart) fairly frequently, but city names tend to stay the same.
|
||||
Another problem is that name needs to reflect not only to the current behaviour, but also the complete history.
|
||||
Another problem is that the name needs to reflect not only the current behaviour, but also the complete history.
|
||||
For example, there are time zones for both "America/New_York" and "America/Detroit".
|
||||
These cities both currently use Eastern Standard Time but in 1969-1972 Michigan (the state in which Detroit is located), did not follow DST, so it needs a different name.
|
||||
It's worth reading the raw time zone database (available at <http://www.iana.org/time-zones>) just to read some of these stories!
|
||||
|
|
|
@ -100,7 +100,7 @@ There are three key steps to creating a new function:
|
|||
Here we have just one argument.
|
||||
If we had more the call would look like `function(x, y, z)`.
|
||||
|
||||
3. You place the code you have developed in **body** of the function, a `{` block that immediately follows `function(...)`.
|
||||
3. You place the code you have developed in the **body** of the function, a `{` block that immediately follows `function(...)`.
|
||||
|
||||
Note the overall process: I only made the function after I'd figured out how to make it work with a simple input.
|
||||
It's easier to start with working code and turn it into a function; it's harder to create a function and then try to make it work.
|
||||
|
@ -915,4 +915,4 @@ R places few limits on your power.
|
|||
You can do many things that you can't do in other programming languages.
|
||||
You can do many things that 99% of the time are extremely ill-advised (like overriding how addition works!).
|
||||
But this power and flexibility is what makes tools like ggplot2 and dplyr possible.
|
||||
Learning how to make best use of this flexibility is beyond the scope of this book, but you can read about in [*Advanced R*](http://adv-r.had.co.nz).
|
||||
Learning how to make best use of this flexibility is beyond the scope of this book, but you can read about it in [*Advanced R*](http://adv-r.had.co.nz).
|
||||
|
|
|
@ -214,7 +214,7 @@ There are two other forms:
|
|||
This is most useful if you only care about side-effects, like plotting or saving a file, because it's difficult to save the output efficiently.
|
||||
|
||||
2. Loop over the names: `for (nm in names(xs))`.
|
||||
This gives you name, which you can use to access the value with `x[[nm]]`.
|
||||
This gives you a name, which you can use to access the value with `x[[nm]]`.
|
||||
This is useful if you want to use the name in a plot title or a file name.
|
||||
If you're creating named output, make sure to name the results vector like so:
|
||||
|
||||
|
|
|
@ -410,7 +410,7 @@ The distinction between `[` and `[[` is most important for lists, as we'll see s
|
|||
|
||||
3. Compare and contrast `setNames()` with `purrr::set_names()`.
|
||||
|
||||
4. Create functions that take a vector as input and returns:
|
||||
4. Create functions that take a vector as input and return:
|
||||
|
||||
a. The last value. Should you use `[` or `[[`?
|
||||
b. The elements at even numbered positions.
|
||||
|
@ -685,7 +685,7 @@ attributes(y)
|
|||
POSIXlts are rare inside the tidyverse.
|
||||
They do crop up in base R, because they are needed to extract specific components of a date, like the year or month.
|
||||
Since lubridate provides helpers for you to do this instead, you don't need them.
|
||||
POSIXct's are always easier to work with, so if you find you have a POSIXlt, you should always convert it to a regular date time `lubridate::as_date_time()`.
|
||||
POSIXct's are always easier to work with, so if you find you have a POSIXlt, you should always convert it to a regular date time with `lubridate::as_date_time()`.
|
||||
|
||||
### Tibbles
|
||||
|
||||
|
|
Loading…
Reference in New Issue