-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathindex.qmd
More file actions
130 lines (95 loc) · 4.89 KB
/
Copy pathindex.qmd
File metadata and controls
130 lines (95 loc) · 4.89 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
---
title: Futureverse
description: A Unifying Parallelization Framework in R for Everyone
preview: images/site_preview.png
bibliography: futureverse.bib
format: html
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = FALSE)
```
<div>
<img src="images/logo.png" alt="The hexlogo of the future package. A left-facing arrow with the text future underneath - both in bold style filled with yellow-to-orange vertical gradient. The background is dark blue with teeny star-shaped symbols in distance resembling looking deep out in the universe. The hexlogo is surrounded by a light-blue border." style="width: 15ex; padding-left: 2ex; padding-top: 1ex; padding-bottom: 1ex; float: right;"/>
The **future** framework makes it easy to parallelize existing R code - often with only a minor change of code. The goal is to lower the barriers so that anyone can safely speed up their existing R code in a worry-free manner. As it is a cross-platform solution that requires no additional setups or technical skills, anyone can be up and running within a few minutes.
The future framework _removes common hurdles and protects against pitfalls_ that follow from adding parallelization. Instead of leaving it to the developers and end-users to be aware of and deal with these problems, they are handled at the core of the highly-validated future ecosystem.
Just as with sequential R code, _output, messages, warnings, and errors work as expected_ and can be handled using traditional R techniques - regardless of how the code is parallelized.
It is designed so that you as a developer can _stay with your favorite coding style_, whether it be base R or tidyverse. If you prefer `lapply()`, `map()` of **purrr**, or `foreach()` of **foreach**, there is _no_ need to switch away from that, e.g. `ys <- map(xs, fcn) |> futurize()`.
In addition to map-reduce calls, the framework supports a large number of domain-specific packages on CRAN and Bioconductor, e.g. `b <- boot(city, ratio, R = 999) |> futurize()` and `ds <- DESeq(ds) |> futurize()`.
Regardless of how you use futures in your code, the user can, with a single setting, switch from running your code sequentially to running it in parallel on their local computer, across multiple machines on their local area network, in the cloud, or distributed on a high-performance compute (HPC) cluster.
Futures make your web interface asynchronous, e.g. a blocking Shiny application can easily be turned into a non-blocking experience by using futures. For further details and motivations of the **future** ecosystem, see @bengtsson-future and @bengtsson-futurize.
</div>
::: {.panel-tabset}
## **Map-reduce calls**
```r
library(futurize)
plan(multisession) # parallelize on local computer
# Evaluate an R expression sequentially
y <- slow_fcn(X[1])
# Evaluate it in parallel in the background
f <- future(slow_fcn(X[1]))
y <- value(f)
# Sequential and parallel version of base R apply
y <- lapply(X, slow_fcn)
y <- lapply(X, slow_fcn) |> futurize()
# Sequential and parallel version of purrr map
library(purrr)
y <- X |> map(slow_fcn)
y <- X |> map(slow_fcn) |> futurize()
# Sequential and parallel version of foreach
library(foreach)
y <- foreach(x = X) %do% slow_fcn(x)
y <- foreach(x = X) %do% slow_fcn(x) |> futurize()
# Sequential and parallel version of plyr
library(plyr)
ys <- llply(xs, sqrt)
ys <- llply(xs, sqrt) |> futurize()
# Sequential and parallel version of BiocParallel
library(BiocParallel)
ys <- bplapply(xs, sqrt)
ys <- bplapply(xs, sqrt) |> futurize()
```
## **Domain-specific calls**
```r
library(futurize)
plan(multisession) # parallelize on local computer
library(boot)
b <- boot(city, ratio, R = 999) |> futurize()
library(glmnet)
cv <- cv.glmnet(x, y) |> futurize()
library(caret)
ctrl <- trainControl(method = "cv", number = 1000)
model <- train(Species ~ ., data = iris, trControl = ctrl) |> futurize()
library(partykit)
cf <- cforest(dist ~ speed, data = cars) |> futurize()
library(stars)
res <- st_apply(s, MARGIN = 1, FUN = mean) |> futurize()
library(vegan)
md <- mrpp(dune, Management) |> futurize()
library(DESeq2)
ds <- DESeq(ds) |> futurize()
library(SingleCellExperiment)
res <- applySCE(sce, perFeatureQCMetrics) |> futurize()
# Many more ...
```
:::
See **[futurize]** for full list of supported packages.
Try it yourself in the [live demo](demo.html).
Looking for **[future.apply]**, **[furrr]**, and **[doFuture]**? Don't
worry, they're still around, but they are now the workhorses operating
fully in the background helping **futurize**.
<!--
<style>
d-title {
background-image: url(images/logo.png);
background-repeat: no-repeat;
background-origin: content-box;
background-position: calc(100% - 4ex);
background-size: 15ex;
min-height: 15ex;
}
</style>
-->
[futurize]: https://futurize.futureverse.org
[future.apply]: https://future.apply.futureverse.org
[furrr]: https://furrr.futureverse.org
[doFuture]: https://doFuture.futureverse.org