# Parallelize base-R apply functions

+ =

The futurize package allows you to easily turn sequential code into parallel code by piping the sequential code to the `futurize()` function. Easy!

# TL;DR

    library(futurize)
    plan(multisession)

    slow_fcn <- function(x) {
      message("x = ", x)
      Sys.sleep(0.1)  # emulate work
      x^2
    }

    xs <- 1:10
    ys <- lapply(xs, slow_fcn) |> futurize()

# Introduction

This vignette demonstrates how to use this approach to parallelize functions such as `lapply()`, `tapply()`, `apply()`, and `replicate()` in the base package, and `kernapply()` in the stats package. For example, consider the base R `lapply()` function, which is commonly used to apply a function to the elements of a vector or a list, as in:

    xs <- 1:1000
    ys <- lapply(xs, slow_fcn)

Here `lapply()` evaluates sequentially, but we can easily make it evaluate in parallel, by using:

    library(futurize)
    plan(multisession) ## parallelize on local machine

    ys <- lapply(xs, slow_fcn) |> futurize()
    #> x = 1
    #> x = 2
    #> x = 3
    #> ...
    #> x = 10

Note how messages produced on parallel workers are relayed as-is back to the main R session as they complete. Not only messages, but also warnings and other types of conditions are relayed back as-is. Likewise, standard output produced by `cat()`, `print()`, `str()`, and so on is relayed in the same way. This is a unique feature of Futureverse - other parallel frameworks in R, such as parallel, foreach with doParallel, and BiocParallel, silently drop standard output, messages, and warnings produced on workers. With futurize, your code behaves the same whether it runs sequentially or in parallel: nothing is lost in translation.

The built-in `multisession` backend parallelizes on your local computer and it works on all operating systems. There are other parallel backends to choose from, including alternatives to parallelize locally as well as distributed across remote machines, e.g.

    plan(future.mirai::mirai_multisession)

and

    plan(future.batchtools::batchtools_slurm)

## Kernel smoothing

    library(futurize)
    plan(multisession)

    library(stats)

    xs <- datasets::EuStockMarkets
    k50 <- kernel("daniell", 50)
    xs_smooth <- kernapply(xs, k = k50) |> futurize()

# Supported Functions

The `futurize()` function supports parallelization of the common base R functions. The following base package functions are supported:

- `lapply()`, `vapply()`, `sapply()`, `tapply()`
- `mapply()`, `.mapply()`, `Map()`
- `eapply()`
- `apply()`
- `replicate()` with `seed = TRUE` as the default
- `by()`
- `Filter()`

The `rapply()` function is not supported by `futurize()`.

The following stats package function is also supported:

- `kernapply()`

# Progress Reporting via progressify

The progressify package is specially designed to work with the Futureverse ecosystem. With progressify, progress can be reported from parallelized computations in a near-live fashion. Progress updates are propagated from the workers back to the main process, where they are relayed to provide feedback during long-running computations. This works because progress is signaled as R conditions that the future package and most future backends relay instantly. What is unique about progressify is that it adds progress reporting to your existing code without you having to change your code.

For example:

    library(futurize)
    plan(multisession)
    library(progressify)

    xs <- 1:100
    ys <- lapply(xs, slow_fcn) |> progressify() |> futurize()

Note how `futurize()` unwraps the expression - it descends through `progressify()` to identify the `lapply()` call to be futurized. Using the default progress handler, the above output and progress reporting will appear as:

    x = 1
    x = 2
    ...
    x = 20
      |=====                    |  20%

# Known issues

The BiocGenerics package defines generic functions `lapply()`, `sapply()`, `mapply()`, and `tapply()`. These S4 generic functions override the non-generic, counterpart functions in the base package, which are only used as a fallback if there is no matching method. For example, in a vanilla R session we have that both of the following calls are identical:

    y_0 <- lapply(1:3, sqrt)
    y_1 <- base::lapply(1:3, sqrt)

However, if we attach the BiocGenerics package, we have that the following two calls are identical:

    library(BiocGenerics)
    y_2 <- lapply(1:3, sqrt)
    y_3 <- BiocGenerics::lapply(1:3, sqrt)

The reason is that `lapply()` here is no longer `base::lapply()`, but the one defined by BiocGenerics, which masks the one in base. We can see this with:

    find("lapply")
    #> [1] "package:BiocGenerics" "package:base"

This matters in the context of futurize. In a vanilla R session,

    y <- lapply(1:3, sqrt) |> futurize()

is identical to

    y <- base::lapply(1:3, sqrt) |> futurize()

However, with BiocGenerics attached, it is instead identical to:

    y <- BiocGenerics::lapply(1:3, sqrt) |> futurize()

which results in:

    Error in transpilers_for_package(type = type, package = ns_name, action = "make",  :
      There are no factory functions for creating 'futurize::add-on' transpilers for package 'BiocGenerics'

The solution is to specify that it is the base version we wish to futurize, i.e.

    y <- base::lapply(1:3, sqrt) |> futurize()