Update rmarkdown.Rmd (#321)

Typo

rmarkdown.Rmd

@@ -151,7 +151,7 @@ The best way to learn these is simply to try them out. It will take a few days,
     
 1.  Download `diamond-sizes.Rmd` from
     <https://github.com/hadley/r4ds/tree/master/rmarkdown>. Check that you
-    can run it, then add text after the frequncy polygon that describes its 
+    can run it, then add text after the frequency polygon that describes its 
     most striking features.
 
 ## Code chunks
@@ -166,7 +166,7 @@ To run code inside an R Markdown document, you need to insert a chunk. There are
 
 Obviously, I'd recommend you learn the keyboard shortcut. It will save you a lot of time in the long run!
 
-You can continue to run code using the keyboard shortcut that by now (I hope!) you know and love: Cmd/Ctrl + Enter. However, chunks get a new keyboard shortcut: Cmd/Ctrl + Shift + Enter, which runs all the code in the chunk. Think of a chunk like a function. A chunk should be relatively self-contained, and focussed around a single task. 
+You can continue to run the code using the keyboard shortcut that by now (I hope!) you know and love: Cmd/Ctrl + Enter. However, chunks get a new keyboard shortcut: Cmd/Ctrl + Shift + Enter, which runs all the code in the chunk. Think of a chunk like a function. A chunk should be relatively self-contained, and focussed around a single task. 
 
 The following sections describe the chunk header which consists of ```` ```{r ````, followed by an optional chunk name, followed by comma separated options, followed by ```` ``` ````.
 
@@ -187,11 +187,11 @@ Chunks can be given an optional name: ```` ```{r by-name} ````. This has three a
 1.  You can set up networks of cached chunks to avoid re-performing expensive
     computations on every run. More on that below.
 
-There is one chunk name that imbues special behaviour: `setup`. When you're in a notebook mode, the chunk named setup will be run automatically once, before anthoer other code is run.
+There is one chunk name that imbues special behaviour: `setup`. When you're in a notebook mode, the chunk named setup will be run automatically once, before other code is ran.
 
 ### Chunk options
 
-Chunk output can be customized with __options__, arguments supplied to chunk header. Knitr provides almost 60 options that you can use to customize your code chunks. Here we'll cover the most important chunk options that you'll use frequently. You can see the full list at <http://yihui.name/knitr/options/>. 
+Chunk output can be customised with __options__, arguments supplied to chunk header. Knitr provides almost 60 options that you can use to customize your code chunks. Here we'll cover the most important chunk options that you'll use frequently. You can see the full list at <http://yihui.name/knitr/options/>. 
 
 The most important set of options controls if your code block is executed and what results are inserted in the finished report:
   
@@ -251,11 +251,11 @@ knitr::kable(
 
 Read the documentation for `?knitr::kable` to see the other ways in which you can customise the table. For even deeper customisation, consider the __xtable__, __stargazer__, __pander__, __tables__, and __ascii__ packages. Each provides a set of tools for returning formatted tables from R code.
 
-There are also a rich set of options for controlling how figures embedded. You'll learn about those in [saving your plots].
+There are also a rich set of options for controlling how figures embedded. You'll learn about these in [saving your plots].
 
 ### Caching
 
-Normally, each knit of a document starts from a completely clean slate. This is great for reproducibility, because it ensures that you've captured every important computation in code. However, it can be painful if you have some computations that take a long time. The solution is `cache = TRUE`. When set, this will save the output of the chunk to a speically named file on disk. On subsequent runs, knitr will check the to see if the code has changed, and if it hasn't, it will re-use the cached results.
+Normally, each knit of a document starts from a completely clean slate. This is great for reproducibility, because it ensures that you've captured every important computation in code. However, it can be painful if you have some computations that take a long time. The solution is `cache = TRUE`. When set, this will save the output of the chunk to a specially named file on disk. On subsequent runs, knitr will check to see if the code has changed, and if it hasn't, it will re-use the cached results.
 
 The caching system must be used with care, because by default it is based on the code only, not its dependencies. For example, here the `processed_data` chunk depends on the `raw_data` chunk: