Repeatedly applying a function

By Higher Order Functions

Google search for "recursion" says "Did you mean recursion?"

(This article was first published on Higher Order Functions, and kindly contributed to R-bloggers)

A colleague of mine sent me the following R question:

I have a function that takes a list and does some stuff to it and then returns
it. I then take that output and run it through the same function again. But I
obviously don’t want to repeatedly type the function out, because I want the
number of function replications to be a declared argument. I had little luck
with functionals, although they
seemed like an obvious choice.

It goes on to say that the solution should work in a magrittr pipeline, so that
will influence how we solve the problem. Namely, we want to write a
function that will transform a pipeline like:

x %>% 
  some_function(args) %>% 
  some_function(args) %>% 
  some_function(args) %>% 
  some_function(args)

into a one-liner like

x %>% 
  repeated(.reps = 4, some_function, args)

Winding up a while loop

The solution is repeated function application with some book-keeping. We could
do this with a while-loop or even with recursion. Here’s the loop version.

repeated <- function(.x, .reps = 1, .f, ...) {
  # A single, finite, non-negative number of repetitions
  assertthat::assert_that(
    length(.reps) == 1,
    !is.na(.reps),
    .reps >= 0,
    is.finite(.reps))
  
  # accept purrr-style formula functions
  .f <- purrr::as_function(.f, ...)
  
  # 0 .reps
  value <- .x

  while (.reps >= 1) {
    value <- .f(value, ...)
    .reps <- .reps - 1
  }

  value
}

We start with some basic input-checking on the number of repetitions.
assert_that() is like stopifnot(), but it spells out failures a little more
verbosely. (To be honest, I don’t like that about half of the function is for
checking the number of repetitions, but that’s how it goes…)

library(purrr)
add <- function(x, y) x + y

10 %>% repeated(-1, add, 2)
#> Error: .reps not greater than or equal to 0
10 %>% repeated(1:10, add, 2)
#> Error: length(.reps) not equal to 1

The next line uses purrr’s as_function(), so that we can also use
formula-based anonymous functions. Here are examples with named functions,
typical anonymous functions and formula-based anonymous functions.

# Regular named function
1:4 %>% repeated(1, add, 2)
#> [1] 3 4 5 6
1:4 %>% repeated(5, add, 2)
#> [1] 11 12 13 14

# Conventional anonymous function
1:4 %>% repeated(2, function(x) x * 2)
#> [1]  4  8 12 16

# Formula-based anonymous function
1:4 %>% repeated(4, ~ .x * 2)
#> [1] 16 32 48 64

# A weird kind of power tower!
1:4 %>% repeated(4, ~ .x ^ 2)
#> [1]          1      65536   43046721 4294967296
((((1:4) ^ 2) ^ 2) ^ 2) ^ 2
#> [1]          1      65536   43046721 4294967296

Because we are working in a pipeline, we expect the first argument to be some
data. If we apply a function 0 times to the data, it should return the data.
That’s why we set the value to the input before the loop.

# 0 function-applications
1:4 %>% repeated(0, add, 2)
#> [1] 1 2 3 4

This function is built around a while-loop that ticks down every time the
function is applied. Generally, loops are not considered idiomatic R. I
certainly try to avoid writing loops in R because the language has built-in
functions that can abstract over a lot of iteration and the required
book-keeping. If we are iterating over a dimension of something, like
elements in a vector or columns in a data-frame, we can probably write a
loop-free version. But here we are not looping over structure—we are looping
through time! This is fundamentally different kind of problem than the kinds
are that solved by Map() or lapply(). That’s why we had to invent our own
higher-order function to handle this kind of iteration for us.

Drilling down with recursion

But we can make it loop-free, by torturing the code into recursion. Okay, it’s
not that bad. Here I break it up into an input-handling step which sets the
stage for the recursive function recursively_repeat().

rrrepeated <- function(.x, .reps = 1, .f, ...) {
  # A single, finite, non-negative number of repetitions
  assertthat::assert_that(
    length(.reps) == 1,
    !is.na(.reps),
    .reps >= 0,
    is.finite(.reps))
  
  # accept purrr-style formula functions
  .f <- purrr::as_function(.f, ...)
  
  recursively_repeat(.x, .reps, .f, ...)
}

recursively_repeat <- function(.x, .reps, .f, ...) {
  if (.reps == 0) {
    .x
  } else { 
    recursively_repeat(.f(.x, ...), .reps - 1, .f, ...)
    # (It would be more correct to use `Recall()` so that renaming the function
    # doesn't break this line... -- how's that for an R deep cut?)
  }
}

This is classic recursion. There are two branches. In the base case, when
there are zero repetitions, the work is done and we return the input In the
recursive case, we re-apply the function, take away one of the repetitions
and then try the recursion again—and again and again until we bottom out
and hit the base case.

This verion works like its buddy:

1:4 %>% repeated(5, ~ .x - 2)
#> [1] -9 -8 -7 -6
1:4 %>% rrrepeated(5, ~ .x - 2)
#> [1] -9 -8 -7 -6

echo <- function(x) paste0(x, " (", x, ")") 
"hello" %>% repeated(2, echo)
#> [1] "hello (hello) (hello (hello))"
"hello" %>% rrrepeated(2, echo)
#> [1] "hello (hello) (hello (hello))"

The main drawback to the recursive version is its readability. I just find it
harder to take in compared to the loop version—at least for a problem this
simple. For more interesting data structures, the recursive version may prove
more elegant and comprehensible.

A minor drawback to the recursive approach is its performance. It’s a little
slower at the median level than the loop approach.

shuffle <- function(x) sample(x)

microbenchmark::microbenchmark(
  with_while = repeated(1:100, 100, shuffle),
  with_recur = rrrepeated(1:100, 100, shuffle),
  times = 1000
)
#> Unit: microseconds
#>        expr     min        lq     mean   median       uq      max neval
#>  with_while 699.331  875.6795 1515.112 1093.551 1589.706 48083.54  1000
#>  with_recur 805.234 1037.1000 1796.680 1342.445 2011.684 13889.58  1000
#>  cld
#>   a 
#>    b

But I don’t usually worry about performance unless I can notice the computation
taking time.

What I will always notice is R trying to protect me from infinite
recursion when I crank up the number of repetition:

repeated(1:20, 1000, shuffle)
#>  [1] 12 14  2 17  7 19  4 10 13  1 20  9 15 11  6 16  5 18  8  3
rrrepeated(1:20, 1000, shuffle)
#> Error: evaluation nested too deeply: infinite recursion / options(expressions=)?

To recap, we had a problem that centered around a specific kind of iteration:
repeatedly applying function on an input. To solve the problem, I wrote a
higher-order function to handle this kind of iteration. My first pass at the
problem used a simple while loop that ticked down a counter every time the
function was called. Dared by the loop-free purism, I also wrote a recursive
version, but for a problem this simple, it’s more of a curiousity.

To leave a comment for the author, please follow the link and comment on their blog: Higher Order Functions.

R-bloggers.com offers daily e-mail updates about R news and tutorials on topics such as: Data science, Big Data, R jobs, visualization (ggplot2, Boxplots, maps, animation), programming (RStudio, Sweave, LaTeX, SQL, Eclipse, git, hadoop, Web Scraping) statistics (regression, PCA, time series, trading) and more…

Source:: R News

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.