library(rray)
library(magrittr)

Introduction

One of the big goals for rray is to be a general purpose toolkit for working with arrays. A requirement of this is that you shouldn’t have to opt into using rray objects to be able to take advantage of broadcasting or the ability to use any of the rray_*() functions. That requirement has been at the core of rray development, and it means that you can use base R vector/matrix/array objects with any of the rray functions, and still get a base R object back out.

Axes

Many of the functions in rray are applied “along an axis”. With base R, you might be used to the MARGIN argument when specifying the dimension to apply a function over. In rray, you’ll use axes (or axis, depending on the function). In short, these two are complements of one another. Ignoring the fact that rray doesn’t drop length 1 dimensions, notice that the values computed in the example below are the same, even though the dimensions to compute over look different.

I find that axes is a more intuitive way to specify the dimensions. This is because with axes, you list the dimensions that you are allowing to change in some way. In the above example, axes = 1 was specified which guarantees that the result will have the same dimensions as x everywhere except in the first dimension, which will have length 1, no matter what. In other words, the dimensions change as: (2, 2, 2) -> (1, 2, 2).

Binding

Reducers aren’t the only functions with this axes guarantee. With rray_bind(), you specify the .axis that you want to bind along. This has the same guarantee that only the .axis specified will be changing. The only caveat here is that the inputs are first broadcast to a common dimension (ignoring the .axis dimension) before the binding is carried out. A few examples might be helpful:

This works by first finding the common dimensions between x and y, ignoring the .axis dimension. So in this case the common dimension is (., 1) where the . represents whatever dimension is actually there for that object. The final result after binding the inputs together will also have a (., 1) shape, where the . will be the sum of all of the 1st dimension sizes of the inputs (in this case 5 + 3 = 8).

The .axis is actually taken account when finding the common dimensions. This means that you can bind along an axis that is higher in dimensionality than any of the inputs. For example, you can bind two matrices along the third dimension.

This works by finding the common dimension between x and x, which is just (5, 1), and then checking that against the .axis. If .axis is implicitly along a higher dimension, the common dimension is extended as needed. In this case it is extended to (5, 1, 1) to match the fact that you are binding along the third dimension. The inputs are broadcast to that shape, and then bound together.

Dimension dropping

One thing you will immediately notice when working with rray is that it often tries not to drop dimensions. This happens most apparently in subsetting, and in the reducers like rray_sum() and is in stark contrast to base R.

The rationale for this has to do with how broadcasting works. When dimensions aren’t dropped, operations such as the following are natural:

This doesn’t work as you might expect with base R, and can result in a tragic error since partial recycling kicks in and you don’t get an error.

This works nicely in rray because of two reasons, both are necessary:

  • The dimensions aren’t dropped
  • Broadcasting kicks in

If you do want to drop dimensions with rray, you can explicitly call rray_squeeze() afterwards. As a rule of thumb, it is much easier to drop dimensions explicitly than it is to recover them.

If you come from NumPy, you might be used to reducers dropping the axis you reduce over. I think this is a mistake, and there have been a number of discussions on the NumPy forums about this choice. Here is why:

For the curious, Julia’s implementation of reducers works similarly to rray.