# Repeatedly applying a function

**Higher Order Functions**, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.

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.

**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 about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.

Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.