# Vectorising like a (semi)pro

**Data Imaginist**, 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.

This is a short practical post about programming with R. Take it for what it is and nothing more…

R is slow! That is what they keep telling us (*they* being someone who “knows”
about “real” programming and has another language that they for some reason fail
to be critical about).

R is a weird thing. Especially for people who has been trained in a classical programming language. One of the main reasons for this is its vectorised nature, which is not just about the fact that vectors are prevalent in the language, but is an underlying principle that should guide the design of efficient algorithms in the language. IF you write R like you write C (or Python), then sure it is slow, but really, you are just using it wrong.

This post will take you through the design of a vectorised function. The genesis of the function comes from my generative art, but I thought it was so nice and self-contained that it would make a good blog post. If that seems like something that could take your mind off the pandemic, then buckle up!

## The problem

I have a height-map, that is, a matrix of numeric values. You know what? Let’s make this concrete and create one:

library(ambient) library(dplyr) z <- long_grid(1:100, 1:100) %>% mutate(val = gen_simplex(x, y, frequency = 0.02)) %>% as.matrix(val) image(z, useRaster = TRUE)

This is just some simplex noise of course, but it fits our purpose…

Anyway, we have a height-map and we want to find the local extrema, that is, the local minimum and maximum. That’s it. Quite a simple and understandable challenge right.

## Vectorised, smecktorised

Now, had you been a trained C-programmer you would probably have solved this with a loop. This is the way it should be done in C, but applying this to R will result in a very annoyed programmer who will tell anyone who cares to listen that R is slow.

We already knew this. We want something vectorised, right? But what is
vectorised anyway? All over the internet the recommendation is to use the
`apply()`

-family of function to vectorise your code, but I have some bad news
for you: This is the absolute wrong way to vectorise. There are a lot of good
reasons to use the functional approach to looping instead of the for-loop, but
when it comes to R, performance is not one of them.

Shit…

To figure this out, we need to be a bit more clear about what we mean with a vectorised function. There are some different ways to think about it

- The broad and lazy definition is a function that operates on the elements of
a vector. This is where
`apply()`

(and friends) based functions reside. - The narrow and performant definition is a function that operates on the
elements of a vector
*in compiled code*. This is where many of R’s base functions live along with properly designed functions implemented in C or C++ - The middle ground is a function that is composed of calls to
*2.*to avoid explicit loops, thus deferring most element-wise operations to compiled code.

We want to talk about *3.*. Simply implementing this in compiled code would be
cheating, and we wouldn’t learn anything.

## Thinking with vectors

R comes with a lot of batteries included. Some of the more high-level function are not implemented with performance in mind (sadly), but a lot of the basic stuff is, e.g. indexing, arithmetic, summations, etc. It turns out that these are often enough to implement pretty complex functions in an efficient vectorised manner.

Going back to our initial problem of finding extrema: What we effectively are
asking for is a moving window function where each cell is evaluated on whether
it is the largest or smallest value in its respective window. If you think a bit
about this, this is mainly an issue of indexing. For each element in the matrix,
we want the indices of all the cells within its window. Once we have that, it is
pretty easy to extract all the relevant values and use the vectorised `pmin()`

and `pmax()`

function to figure out the maximum value in the window and use the
(vectorised) `==`

to see if the extrema is equivalent to the value of the cell.

That’s a lot of talk, here is the final function:

extrema <- function(z, neighbors = 2) { ind <- seq_along(z) rows <- row(z) cols <- col(z) n_rows <- nrow(z) n_cols <- ncol(z) window_offsets <- seq(-neighbors, neighbors) window <- outer(window_offsets, window_offsets * n_rows, `+`) window_row <- rep(window_offsets, length(window_offsets)) window_col <- rep(window_offsets, each = length(window_offsets)) windows <- mapply(function(i, row, col) { row <- rows + row col <- cols + col new_ind <- ind + i new_ind[row < 1 | row > n_rows | col < 1 | col > n_cols] <- NA z[new_ind] }, i = window, row = window_row, col = window_col, SIMPLIFY = FALSE) windows <- c(windows, list(na.rm = TRUE)) minima <- do.call(pmin, windows) == z maxima <- do.call(pmax, windows) == z extremes <- matrix(0, ncol = n_cols, nrow = n_rows) extremes[minima] <- -1 extremes[maxima] <- 1 extremes }

(don’t worry, we’ll go through it in a bit)

This function takes a matrix, and a neighborhood radius and returns a new matrix
of the same dimensions as the input, with `1`

in the local maxima, `-1`

in the
local minima, and `0`

everywhere else.

Let’s go through it:

# ... ind <- seq_along(z) rows <- row(z) cols <- col(z) n_rows <- nrow(z) n_cols <- ncol(z) # ...

Here we are simply doing some quick calculations upfront for reuse later. The
ind variable is simply the index for each cell in the matrix. Matrices are
simply vectors underneath, so they can be indexed like that as well. `rows`

and
`cols`

holds the row and column index of each cell, and `n_rows`

and `n_cols`

are pretty self-explanatory.

# ... window_offsets <- seq(-neighbors, neighbors) window <- outer(window_offsets, window_offsets * n_rows, `+`) window_row <- rep(window_offsets, length(window_offsets)) window_col <- rep(window_offsets, each = length(window_offsets)) # ...

Most of the magic happens here, but it is not that apparent. What we do is that
we use the `outer()`

function to construct a matrix, the size of our window,
holding the index offset from the center for each of the cells in the window. We
also construct vectors holding the rows and column offset for each cell

# ... windows <- mapply(function(i, row, col) { row <- rows + row col <- cols + col new_ind <- ind + i new_ind[row < 1 | row > n_rows | col < 1 | col > n_cols] <- NA z[new_ind] }, i = window, row = window_row, col = window_col, SIMPLIFY = FALSE) # ...

This is where all the magic appear to happen. For each cell in the window, we
are calculating it’s respective value for each cell in the input matrix. I can
already hear you scream about me using and `apply()`

-like function, but the key
thing is that I’m not using it to loop over the elements of the input vector (or
matrix), but over a much smaller (and often fixed) number of elements.

If you want to leave now because I’m moving the goal-posts by my guest.

Anyway, what is happening inside the `mapply()`

call? Inside the function we
figure out which row and column the offsetted cell is part of. Then we calculate
the index of the cells for the offset. In order to guard against out-of-bounds
errors we set all the indices that are out of bound to `NA`

, and then we simply
index into our matrix. The crucial part is that all of the operations here are
vectorised (indexing, arithmetic, and comparisons). In the end we get a list
holding vectors of values for each cell in the window.

# .. windows <- c(windows, list(na.rm = TRUE)) minima <- do.call(pmin, windows) == z maxima <- do.call(pmax, windows) == z extremes <- matrix(0, ncol = n_cols, nrow = n_rows) extremes[minima] <- -1 extremes[maxima] <- 1 extremes # ..

This is really just wrapping up, even though the actual computations are
happening here. We use `pmin()`

and `pmax()`

to find the maximum and minimum
across each window, and compare it to the value in our input matrix (again, all
proper vectorised function). In the end we construct a matrix holding `0`

s and
use the calculated positions to set `1`

or `-1`

at the location of local
extremes.

## Does it work?

I guess that is the million dollar question, closely followed by “is it
faster?”. I don’t really care enough to implement a “dumb” vectorisation, so
I’ll just put my head on the block with the last question and insist that, yes,
it is much faster. You can try to beat me with an `apply()`

based solution and
I’ll eat a sticker if you succeed (unless you cheat).

As for the first question, let’s have a look

extremes <- extrema(z) extremes[extremes == 0] <- NA image(z, useRaster = TRUE) image(extremes, col = c('black', 'white'), add = TRUE)

Lo and behold, it appears as if we succeeded.

## Can vectorisation save the world?

No…

More to the point, not every problem has a nice vectorised solution. Further, the big downside with proper vectorisation is that it often requires expanding a lot of variables to the size of the input vector. In our case we needed to hold all windows in memory simultaneously, and it does not take too much imagination to think up scenarios where that may make our computer explode. Still, more often than not it is possible to write super performant R code, and usually the crucial part is to figure out how to do some intelligent indexing.

If you are still not convinced then read through Brodie Gaslam’s blog. He has a penchant for implementing ridiculously complicated stuff in highly efficient R code. It goes without saying that his posts are often more involved than this, but if you have kept reading until this point, I think you are ready…

**leave a comment**for the author, please follow the link and comment on their blog:

**Data Imaginist**.

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.