From d150dce730a42c7f9109c0cd4ee2ad3a5529f163 Mon Sep 17 00:00:00 2001 From: Shannon Ellis Date: Fri, 19 Aug 2016 15:53:34 -0400 Subject: [PATCH 1/3] Update iteration.Rmd (#292) minor typo --- iteration.Rmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iteration.Rmd b/iteration.Rmd index e03cf22..9779384 100644 --- a/iteration.Rmd +++ b/iteration.Rmd @@ -15,7 +15,7 @@ In [functions], we talked about how important it is to reduce duplication in you 1. You're likely to have fewer bugs because each line of code is used in more places. -One tool for reducing duplication is functions, which reduce duplication by identifying repeated patterns of code and extract them out into independent pieces that can be easily reused and updated. Another toolf for reducing duplication is __tteration__, which helps you when you need to do the same thing to multiple inputs: repeating the same operation on different columns, or on different datasets. +One tool for reducing duplication is functions, which reduce duplication by identifying repeated patterns of code and extract them out into independent pieces that can be easily reused and updated. Another tool for reducing duplication is __iteration__, which helps you when you need to do the same thing to multiple inputs: repeating the same operation on different columns, or on different datasets. In this chapter you'll learn about two important iteration paradigms: imperative programming and functional programming. On the imperative side you have tools like for loops and while loops, which are a great place to start because they make iteration very explicit, so it's obvious what's happening. However, for loops are quite verbose, and require quite a bit of bookkeeping code that is duplicated for every for loop. Functional programming (FP) offers tools to extract out this duplicated code, so each common for loop pattern gets its own function. Once you master the vocabulary of FP, you can solve many common iteration problems with less code, more ease, and fewer errors. ### Prerequisites From 1913474b52625dee8c39c07d14e6077f498bfd0e Mon Sep 17 00:00:00 2001 From: Thomas Klebel Date: Sun, 21 Aug 2016 00:24:27 +0200 Subject: [PATCH 2/3] fix typos in transform (#294) --- transform.Rmd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/transform.Rmd b/transform.Rmd index 24198f1..e4ba149 100644 --- a/transform.Rmd +++ b/transform.Rmd @@ -93,14 +93,14 @@ sqrt(2) ^ 2 == 2 1/49 * 49 == 1 ``` -Computers use finite precision arithmetic (they obviously can't store an infinite number of digits!) so remember that every number you see is an approximation. Instead of relying on `==`, use use `dplyr::near()`: +Computers use finite precision arithmetic (they obviously can't store an infinite number of digits!) so remember that every number you see is an approximation. Instead of relying on `==`, use `dplyr::near()`: ```{r} near(sqrt(2) ^ 2, 2) near(1 / 49 * 49, 1) ``` -(Remember that we use `::` to explicit about where a function lives. If dplyr is installed, `dplyr::near()` will always work. If you want to use the shorter `near()`, you need to make sure you have loaded dplyr with `library(dplyr)`.) +(Remember that we use `::` to be explicit about where a function lives. If dplyr is installed, `dplyr::near()` will always work. If you want to use the shorter `near()`, you need to make sure you have loaded dplyr with `library(dplyr)`.) ### Logical operators From 947a5da3c17a113e316791aed7cbf6162dc1c87e Mon Sep 17 00:00:00 2001 From: S'busiso Mkhondwane Date: Sun, 21 Aug 2016 00:26:10 +0200 Subject: [PATCH 3/3] Update functions.Rmd (#293) Small typo --- functions.Rmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/functions.Rmd b/functions.Rmd index 8cb9f1b..e27ef00 100644 --- a/functions.Rmd +++ b/functions.Rmd @@ -662,7 +662,7 @@ Figuring out what your function should return is usually straightforward: it's w ### Explicit return statements -The value returned by the function is the usually the last statement it evaluates, but you can choose to return early by using `return()`. I think it's best to save the use of `return()` to signal that you can return early with a simpler solution. A common reason to do this is because the inputs are empty: +The value returned by the function is usually the last statement it evaluates, but you can choose to return early by using `return()`. I think it's best to save the use of `return()` to signal that you can return early with a simpler solution. A common reason to do this is because the inputs are empty: ```{r} complicated_function <- function(x, y, z) {