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.