magrittr
% > %
When writing code, it is common to work on one object for a while. For example, when we need to import data, then work with that data to clean it, add columns, delete some, summarize data, etc.
To start, consider a simple example:
t <- tibble(“x” = runif(10)) t <- within(t, y <- 2 * x + 4 + rnorm(10, mean=0,sd=0.5))
This can also be written with the piping operator from magrittr
t <- tibble(“x” = runif(10)) %>% within(y <- 2 * x + 4 + rnorm(10, mean=0,sd=0.5))
What R does behind the scenes, is feeding the output left of the pipe operator as main input right of the pipe operator. This means that the following are equivalent:
# 1. pipe: a %>% f() # 2. pipe with shortened function: a %>% f # 3. is equivalent with: f(a)
Example: – Pipe operator
a <- c(1:10)
a %>% mean()
## [1] 5.5
a %>% mean
## [1] 5.5
mean(a)
## [1] 5.5
It might be useful to pronounce the pipe operator, %>% as “then” to understand what it does.
# The following line
c <- a %>%
f()
# is equivalent with:
c <- f(a)
# Also, it is easy to see that
x <- a %>% f(y) %>% g(z)
# is the same as:
x <- g(f(a, y), z)
7.3.3 Attention Points When Using the Pipe
This construct will get into problems for functions that use lazy evaluation. Lazy evaluation is a feature of R that is introduced in R to make it faster in interactive mode. This means that those functions will only calculate their arguments when they are really needed. There is of course a good reason why those functions have lazy evaluation and the reader will not be surprised that they cannot be used in a pipe. So there are many functions that use lazy evaluation, but most notably are the error handlers. These are functions that try to do something, but when an error is thrown or a warning message is generated, they will hand it over to the relevant handler. Examples are try, tryCatch, etc. We do not really discuss error handling in any other parts of this book, so here is a quick primer.
try()
tryCatch()
handler
# f1 # Dummy function that from which only the error throwing part 0 # is shown. f1 <- function() { # Here goes the long code that might be doing something risky # (e.g. connecting to a database, uploading file, etc.) # and finally, if it goes wrong: stop(“Early exit from f1!”) # throw error } tryCatch(f1(), # the function to try error = function(e) {paste(“_ERROR_:”,e)}, warning = function(w) {paste(“_WARNING_:”,w)}, message = function(m) {paste(“_MESSSAGE_:”,m)}, finally=“Last command” # do at the end ) ## [1] “_ERROR_: Error in f1(): Early exit from f1!\n”
As can be understood from the example above, the error handler should not be evaluated if f1 does not throw an error. That is why they use error handling. So the following will not work:
# f1 # Dummy function that from which only the error throwing part # is shown. f1 <- function() { # Here goes the long code that might be doing something risky # (e.g. connecting to a database, uploading file, etc.) # and finally, if it goes wrong: stop(“Early exit from f1!”) # something went wrong } %>% tryCatch( error = function(e) {paste(“_ERROR_:”,e)}, warning = function(w) {paste(“_WARNING_:”,w)}, message = function(m) {paste(“_MESSSAGE_:”,m)}, finally=“Last command” # do at the end ) # Note that it fails in silence.
There is a lot more to error catching than meets the eye here. We recommend to read the documentation of the relevant functions carefully. Another good place to start is “Advanced R,” page 163, Wickham (2014).
Another issue when using the pipe operator %>% occurs when functions use explicitely the current environment. In those functions, one will have to be explicit which environment to use. More about environments and scoping can be found in Chapter 5 on page 81.
7.3.4 Advanced Piping
7.3.4.1 The Dollar Pipe
Below we create random data that has a linear dependency and try to fit a linear model on that data.12
# This will not work, because lm() is not designed for the pipe. lm1 <-
