2.5 Resampling

Resampling strategies are usually used to assess the performance of a learning algorithm. mlr3 entails 6 predefined resampling strategies: Cross-validation, Leave-one-out cross validation, Repeated cross-validation, Out-of-bag bootstrap and other variants (e.g. b632), Monte-Carlo cross-validation and Holdout. The following sections provide guidance on how to set and select a resampling strategy and how to subsequently instantiate the resampling process.

2.5.1 Settings

In this example we use the iris task and a simple classification tree (package rpart).

When performing resampling with a dataset, we first need to define which approach should be used. The resampling strategies of mlr3 can be queried using the .$keys() method of the mlr_resamplings dictionary.

Additional resampling methods for special use cases will be available via extension packages, such as mlr3spatiotemporal for spatial data (still in development).

The model fit conducted in the train/predict/score chapter is equivalent to a “holdout”, so let’s consider this one first. Again, we can retrieve elements via $get() or with a convenience function (rsmp()):

Note that the Instantiated field is set to FALSE. This means we did not actually apply the strategy on a dataset yet, but just performed a dry-run. Applying the strategy on a dataset is done in section next Instantiation.

By default we get a .66/.33 split of the data. There are two ways in which the ratio can be changed:

  1. Overwriting the slot in .$param_set$values using a named list:
  1. Specifying the resampling parameters directly during construction:

2.5.2 Instantiation

So far we just set the stage and selected the resampling strategy. To actually perform the splitting, we need to apply the settings on a dataset. This can be done in two ways:

  1. Manually by calling the method .$instantiate() on a Task:
  1. Automatically by passing the resampling object to resample(). Here, the splitting is done within the resample() call based on the supplied Task:

If you want to compare multiple learners, you should use the same resampling per task to reduce the variance of the performance estimation (method 1). If you use method 2 (and do not instantiate manually before), the resampling splits will differ between both runs.

If your aim is to compare different Task, Learner or Resampling, you are better off using the benchmark() function. It is basically a wrapper around resample() simplifying the handling of multiple settings.

If you discover this only after you’ve run multiple resample() calls, don’t worry. You can transform multiple single ResampleResult objects into a BenchmarkResult (explained later) using the .$combine() method.

2.5.3 Execution

With a Task, a Learner and Resampling object we can call resample() and create a ResampleResult object.

Before we go into more detail, let’s change the resampling to a “3-fold cross-validation” to better illustrate what operations are possible with a ResampleResult. Additionally, we tell resample() to keep the fitted models via the flag store_models:

The following operations are supported with ResampleResult objects:

  • Extract the performance for the individual resampling iterations:
  • Extract and inspect the resampling splits:
  • Retrieve the learner of a specific iteration and inspect it:

2.5.4 Custom resampling

Sometimes it is necessary to perform resampling with custom splits. If you want to do that because you are coming from a specific modeling field, first take a look at the mlr3 extension packages. It is important to make sure that your custom resampling method has not been implemented already.

If your custom resampling method is widely used in your field, feel welcome to integrate it into one of the existing mlr3 extension packages. You could also create your own extension package.

A manual resampling instance can be created using the "custom" template.