User Rating: 1 / 5      Today, we published the first version of a new `R` package at github.com/thomasWeise/functionComposeR for composing and canonicalizing functions. When we combine functions in `R` in the form of `g(f(x))`, we have the problem that the result is rarely human readable. This results from two problems. The first problem is that variables inside the function are evaluated in the environment of the function and even if they are constants, they will remain as variables. Thus, when printing a function `f(x)`, I may sometimes something like a `k*x` inside, but may not know the value of `k`, even though it may be perfectly known in the function's environment and a constant. The second problem is that this also applies to nested functions, so there may be something like `f=function(x) x+g(x)` where `g` is a well-defined function, but printing `f` will not reveal the nature of `g`. Both of these issues also make evaluating the functions slower, as we could resolve the variables to constants and inline the nested functions' bodies, but instead evaluate them as variables and function calls, respectively. With our new package, we try to solve all of these issues at once. We provide a tool for combining functions and one for canonicalizing functions, i.e., for resolving all resolve-able components of a function.

### 1. Motivating Example

As example, assume you have set `k` and now want to compose the functions `f<-function(x) { (k*x) + 7 }` and `g<-function(x) { (k*k-x*x) / (x - sin(k)) }` to a function `h`. You can do that by writing `h<-function(x) g(f(x))`. Of course, if you later try to inspect `h` and just write `h` in the `R` console, you will see exactly this: `function(x) g(f(x))`.

This leads to two issues: First, if you do not know `f` and `g`, the output is meaningless and opaque, you cannot interpret it. Second, evaluating `h` is unnecessarily slow: It performs two inner function calls and needs to evaluate a variable `k` at several locations, although the value of `k` should be fixed to `23`. Matter of fact, also `k*k` and `sin(k)` are constants which could be known.

The goal of our new function `function.compose` is to resolve these two issues. If you do `h<-function.compose(f, g)` instead of `h<-function(x) g(f(x))`, a new function composed of both the bodies of `f` and `g` is created. Furthermore, as many of the variables and expressions in the body which can be resolved as possible are replaced by their constant result. Printing the result of `h<-function.compose(f, g)` would yield the readable and fast function:

```function (x)
{
x <- (23 * x) + 7
(529 - x * x)/(x - -0.846220404175171)
}
```

### 2. Detailed Example

Let us now look at some more complex composed functions and also check the performance of the composed functions.

#### 2.1. Simple Composition

First, we again compose two functions which also access some variables from the environment.

```i<-45
j<-33
k<-23
f <- function(x) { (x*(x-i)) - x/sinh(k*cos(j-atan(k+j))) }
g <- function(x) { abs(x)^(abs(1/(3-i))) + (j - k*exp(-i)) / ((i*j) * x) }
h.1.plain <- function(x) g(f(x))
h.1.composed <- function.compose(f, g)
```

Printing `h.1.plain` and `h.1.composed` again reveals the difference between ordinary function composition in `R` and function composition using our functionComposeR package:

```h.1.plain
# function(x) g(f(x))
h.1.composed
# function (x)
# {
#     x <- (x * (x - 45)) - x/4818399372.40284
#     abs(x)^0.0238095238095238 + 33/(1485 * x)
# }
```

#### 2.2. Nested Function Composition

But we can also compose multiple functions, i.e., do

```h.2.plain <- function(x) g(f(g(f(x))))
h.2.composed <- function.compose(function.compose(function.compose(f, g), f), g)
```

which yields functions of the form

```h.2.plain
# function(x) g(f(g(f(x))))
h.2.composed
# function (x)
# {
#     x <- {
#         x <- {
#             x <- (x * (x - 45)) - x/4818399372.40284
#             abs(x)^0.0238095238095238 + 33/(1485 * x)
#         }
#         (x * (x - 45)) - x/4818399372.40284
#     }
#     abs(x)^0.0238095238095238 + 33/(1485 * x)
# }
```

#### 2.3. Benchmarking

Let us finally evaluate the performance of the composed functions versus their plain counterparts. We therefore use the package microbenchmark.

```x <- runif(1000)
library(microbenchmark)
microbenchmark(h.1.plain(x), h.1.composed(x), h.2.plain(x), h.2.composed(x))
# Unit: microseconds
#             expr     min       lq      mean   median       uq     max neval
#     h.1.plain(x)  78.841  79.4880  83.05224  79.9775  85.8485 119.824   100
#  h.1.composed(x)  75.890  76.4675  93.23504  76.8385  78.9615 896.681   100
#     h.2.plain(x) 153.793 154.8100 166.31210 155.5855 164.3685 743.360   100
#  h.2.composed(x) 149.035 149.4870 155.25070 149.8895 154.0960 213.395   100
```

From the result, it becomes clearly visible that the upper quartiles of the runtime consumption of the composed functions are below the lower quartiles of the runtime consumption of their plain counterparts. Obviously, this very strongly depends on the example, but it is a clear indicator that our package can compose functions in way that is both human-readable and quick to evaluate.

### 3. Canonicalizing Functions

Canonicalizing an existing function means to resolve all of its resolvable components. This means that variables which can be replaced by constants will be, and that sub-expressions which can be evaluated to constants will be so as well.

```f <- function(x) { 5+3+x }
function.canonicalize(f)
# function (x)
# 8 + x
z <- 24;
g <- function(x) { tan(sin(z) + (z*27) / x) }
function.canonicalize(g)
# function (x)
# tan(-0.905578362006624 + 648/x)```

### 4. Installation Instructions

You can install the package directl from GitHub by using the package `devtools` as follows:

```library(devtools)
install_github("thomasWeise/functionComposeR")
```

If `devtools` is not yet installed on your machine, you need to FIRST do

```install.packages("devtools")
```

I hope our package can be useful for other `R` programmers. It is published under the LGPL v3 license.