add section about mirai

book/chapters/chapter1/introduction_and_overview.qmd

@@ -3,6 +3,16 @@ aliases:
   - "/introduction_and_overview.html"
 ---
 
+
+```{r}
+# extra packages that must be installed in the docker image
+remotes::install_github("mlr-org/mlr3@mirai")
+remotes::install_github("mlr-org/mlr3pipelines")
+remotes::install_github("mlr-org/mlr3fairness@weights")
+remotes::install_github("mlr-org/mlr3learners")
+remotes::install_github("r-lib/mirai")
+```
+
 # Introduction and Overview {#sec-introduction}
 
 {{< include ../../common/_setup.qmd >}}

book/chapters/chapter10/advanced_technical_aspects_of_mlr3.qmd

@@ -491,6 +491,101 @@ lrn_rpart$parallel_predict = TRUE
 prediction = lrn_rpart$predict(tsk_sonar)
 ```
 
+### Parallelization with `mirai` {#sec-parallel-mirai}
+
+```{r, include = FALSE}
+mirai::daemons(0)
+```
+
+With `mlr3` 1.0.0, we integrated the `r ref_pkg("mirai")` package as an alternative parallelization backend.
+`mirai` provides a lightweight approach to parallelization by starting persistent R sessions called daemons that evaluate tasks in parallel.
+These daemons can be launched either locally or on remote machines via SSH or cluster managers.
+Compared to the `r ref_pkg("future")` package, `mirai` has significantly lower overhead per task.
+Like parallelization with `future`, users only need to configure the backend before starting any computations.
+The following sections demonstrate how to use `mirai` for parallelizing resamplings, benchmarks, and tuning.
+
+To use `mirai` for parallelization, we first need to start the daemons.
+We start two daemons and check the status of the daemons.
+
+```{r, eval = FALSE}
+library(mirai)
+
+mirai::daemons(2)
+
+mirai::status()
+```
+
+We parallelize a three-fold CV for a decision tree on the sonar task.
+
+```{r}
+tsk_sonar = tsk("sonar")
+lrn_rpart = lrn("classif.rpart")
+rsmp_cv3 = rsmp("cv", folds = 3)
+system.time({resample(tsk_sonar, lrn_rpart, rsmp_cv3)})
+```
+
+One advantage of `mirai` is that it eliminates the need to manually set chunk sizes, as it automatically handles task distribution efficiently.
+
+Since the daemons are already running, we can proceed directly with the tuning example.
+
+```{r}
+instance = tune(
+  tnr("random_search", batch_size = 12),
+  tsk("penguins"),
+  lrn("classif.rpart", minsplit = to_tune(2, 128)),
+  rsmp("cv", folds = 3),
+  term_evals = 20
+)
+
+instance$archive$n_evals
+```
+
+`mirai` also supports nested resampling, where the outer loop can be parallelized while the inner loop runs sequentially.
+We start a daemon for each outer resampling iteration.
+The inner loop runs sequentially.
+
+```{r}
+# reset daemons
+mirai::daemons(0)
+
+mirai::daemons(5)
+
+lrn_rpart = lrn("classif.rpart",
+  minsplit  = to_tune(2, 128))
+
+lrn_rpart_tuned = auto_tuner(tnr("random_search", batch_size = 2),
+  lrn_rpart, rsmp("cv", folds = 3), msr("classif.ce"), 2)
+
+rr = resample(tsk("penguins"), lrn_rpart_tuned, rsmp("cv", folds = 5))
+```
+
+We can also parallelize both outer and inner loops using the `everywhere()` function to set up daemons for the inner loop on the daemons of the outer loop.
+
+```{r, eval = FALSE}
+# reset daemons
+mirai::daemons(0)
+
+mirai::daemons(5)
+
+everywhere({
+  mirai::daemons(3)
+})
+```
+
+Note that running the outer loop in the main session while parallelizing the inner loop is currently not supported.
+However, you can run the outer loop in a single daemon and the inner loop on multiple daemons
+
+```{r, eval = FALSE}
+# reset daemons
+mirai::daemons(0)
+
+mirai::daemons(1)
+
+everywhere({
+  mirai::daemons(3)
+})
+```
+
 ## Error Handling {#sec-error-handling}
 
 In large experiments, it is not uncommon that a model fit or prediction fails with an error.\index{debugging}

book/chapters/chapter2/data_and_basic_modeling.qmd

@@ -1027,7 +1027,8 @@ There are seven column roles:
 4. `"order"`: Variable(s) used to order data returned by `$data()`; must be sortable with `order()`.
 5. `"group"`: Variable used to keep observations together during resampling.
 6. `"stratum"`: Variable(s) to stratify during resampling.
-7. `"weight"`: Observation weights. Only one numeric column may have this role.
+7. `"weights_learner"`: Weights used during training by the learner. Only one numeric column may have this role.
+8. `"weights_measure"`: Weights used during scoring by the measure. Only one numeric column may have this role.
 
 We have already seen how features and targets work in @sec-tasks, which are the only column roles that each task must have.
 In @sec-strat-group we will have a look at the `stratum` and `group` column roles.
@@ -1051,7 +1052,7 @@ tsk_mtcars_order$data(ordered = TRUE)
 In this example we can see that by setting `"idx"` to have the `"order"` column role, it is no longer used as a feature when we run `$data()` but instead is used to order the observations according to its value.
 This metadata is not passed to a learner.
 
-The `weights` column role is used to weight data points differently.
+The `weights_learner` column role is used to weight data points differently.
 One example of why we would do this is in classification tasks with severe class imbalance, where weighting the minority class more heavily may improve the model's predictive performance for that class.
 For example in the `breast_cancer` dataset, there are more instances of benign tumors than malignant tumors, so if we want to better predict malignant tumors we could weight the data in favor of this class:
 
@@ -1065,7 +1066,7 @@ df$weights = ifelse(df$class == "malignant", 2, 1)
 
 # create new task and role
 cancer_weighted = as_task_classif(df, target = "class")
-cancer_weighted$set_col_roles("weights", roles = "weight")
+cancer_weighted$set_col_roles("weights", roles = "weights_learner")
 
 # compare weighted and unweighted predictions
 split = partition(cancer_unweighted)

book/chapters/chapter9/preprocessing.qmd

@@ -239,6 +239,7 @@ magick::image_trim(fig)
 Using this pipeline we can now run experiments with `lrn("regr.ranger")`, which cannot handle missing data; we also compare a simpler pipeline that only uses OOR imputation to demonstrate performance differences resulting from different strategies.
 
 ```{r preprocessing-015}
+#| eval: false
 glrn_rf_impute_hist = as_learner(impute_hist %>>% lrn("regr.ranger"))
 glrn_rf_impute_hist$id = "RF_imp_Hist"