Error: target transformation in spatial regression tasks

[jgloeggler]

library(mlr3)
library(mlr3spatiotempcv)
library(mlr3learners)
library(mlr3pipelines)

task = tsk("cookfarm_mlr3")

log_task = mlr3pipelines::PipeOpTargetMutate$new("logtrafo", param_vals = list(
  trafo = function(x) log(x),
  inverter = function(x) list(response = exp(x)$response))
)

log_task$train(list(task))

Results in:

Error in .__Task__col_roles(self = self, private = private, super = super,  : 
  Assertion on 'names of col_roles' failed: Names must be a permutation of set {'feature','target','name','order','stratum','group','weight','coordinate','space','time'}, but has extra elements {'always_included'}.
This happened PipeOp logtrafo's $train()

[advieser]

Hey, thanks for the issue!

I can't reproduce this directly. You probably also have mlr3fselect loaded? Otherwise, you shouldn't have the possible col_role "always_included". You can check this using utils::sessionInfo().

If the error occurs then depends on the load order of the packages:

• If we load mlr3fselect before mlr3spatiotempcv, the code should be able to run.
• If we load mlr3fselect after mlr3spatiotempcv, the code fails, as it does in your case.

So if you don't need mlr3fselect just make sure to not load it, or make sure to load it before mlr3spatiotempcv if you need it.
Still, this error should probably not occur, and this is only a workaround, so thank you very much for reporting it! And let us know, if this still doesn't work.

[advieser]

Explanation for us internally: Why does the load order make a difference?

• The error occurs in the assignment of col_roles called from mlr3::convert_task() if there is a mismatch between the col_roles of intask and the col_roles registered in mlr_reflections$task_col_roles for the task_type of the newtask.
• If mlr3fselect is loaded before constructing tsk("cookfarm_mlr3"), the task will always have the col_role "always_included" (probably because TaskRegrST calls super$initialize). The difference is whether mlr_reflections$task_col_roles$regr_st contains "always_included" or not.
• mlr3spatiotempcv adds the new task types classif_st and regr_st to mlr_reflections$task_col_roles by copying the already registered col_roles for regr and classif and appending "coordinate", "space", and "time" (see here).
• If mlr3fselect was loaded before mlr3spatiotempcv, these already registered col_roles for regr and classif also contain "always_included", so there would be no mismatch.
• On the other hand if mlr3fselect gets loaded after mlr3spatiotempcv, mlr_reflections$task_col_roles$regr_st wil not contain "always_included" and there is a mismatch.

This fails:

library(mlr3)
library(mlr3spatiotempcv)
library(mlr3fselect)
mlr_reflections$task_col_roles
# $regr
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"
# [8] "always_included"
#
# $classif
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"
# [8] "always_included"
#
# $unsupervised
# [1] "feature" "name"    "order"
#
# $classif_st
# [1] "feature"    "target"     "name"       "order"      "stratum"    "group"      "weight"     "coordinate" "space"      "time"
#
# $regr_st
# [1] "feature"    "target"     "name"       "order"      "stratum"    "group"      "weight"     "coordinate" "space"      "time"
library(mlr3learners)
library(mlr3pipelines)

task = tsk("cookfarm_mlr3")
task$col_roles
# $feature
# [1] "BLD"      "HZDUSD"   "LHDICM"   "Port1C"   "Port1EC"  "Port1VW"  "Port2C"   "Port2EC"  "Port2VW"  "Port3C"   "Port3EC"
# [12] "Port3VW"  "Port4C"   "Port4EC"  "Port4VW"  "Port5C"   "Port5EC"  "Port5VW"  "TAXSUSDA" "UHDICM"
#
# $target
# [1] "PHIHOX"
#
# $name
# character(0)
#
# $order
# character(0)
#
# $stratum
# character(0)
#
# $group
# character(0)
#
# $weight
# character(0)
#
# $always_included
# character(0)
#
# $coordinate
# [1] "x" "y"
#
# $space
# [1] "SOURCEID"
#
# $time
# [1] "Date"

log_task = mlr3pipelines::PipeOpTargetMutate$new("logtrafo", param_vals = list(
  trafo = function(x) log(x),
  inverter = function(x) list(response = exp(x)$response))
)

log_task$train(list(task))

This works:

library(mlr3)
library(mlr3fselect)
library(mlr3spatiotempcv)
mlr_reflections$task_col_roles
# $regr
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"         
# [8] "always_included"
# 
# $classif
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"         
# [8] "always_included"
# 
# $unsupervised
# [1] "feature" "name"    "order"  
# 
# $classif_st
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"         
# [8] "always_included" "coordinate"      "space"           "time"           
# 
# $regr_st
# [1] "feature"         "target"          "name"            "order"           "stratum"         "group"           "weight"         
# [8] "always_included" "coordinate"      "space"           "time"           
library(mlr3learners)
library(mlr3pipelines)

task = tsk("cookfarm_mlr3")
task$col_roles
# $feature
# [1] "BLD"      "HZDUSD"   "LHDICM"   "Port1C"   "Port1EC"  "Port1VW"  "Port2C"   "Port2EC"  "Port2VW"  "Port3C"   "Port3EC" 
# [12] "Port3VW"  "Port4C"   "Port4EC"  "Port4VW"  "Port5C"   "Port5EC"  "Port5VW"  "TAXSUSDA" "UHDICM"  
# 
# $target
# [1] "PHIHOX"
# 
# $name
# character(0)
# 
# $order
# character(0)
# 
# $stratum
# character(0)
# 
# $group
# character(0)
# 
# $weight
# character(0)
# 
# $always_included
# character(0)
# 
# $coordinate
# [1] "x" "y"
# 
# $space
# [1] "SOURCEID"
# 
# $time
# [1] "Date"

log_task = mlr3pipelines::PipeOpTargetMutate$new("logtrafo", param_vals = list(
  trafo = function(x) log(x),
  inverter = function(x) list(response = exp(x)$response))
)

log_task$train(list(task))

[mb706]

My guess is that the easiest patch for us would be to check in the constructor of TaskXST whether we should drop col-roles (e.g. here). But it could also be mlr3fselect's responsibiliity to make sure the new col-role exists in all tasks.

This may be a more fundamental question of how we want to handle modifications of mlr_reflections by packages. We should definitely talk about this internally. @mllg @berndbischl @be-marc do you want to have a look here?

@jgloeggler it seems that currently the necessary workaround is to first load library(mlr3fselect) before library(mlr3spatiotempcv); is that an option in your use-case?

[be-marc]

Fixed for mlr3fselect mlr-org/mlr3fselect#145. mlr3fselect assigns "always_included" to all tasks now.

[be-marc]

The issue still exists when a package defines a new tasks class which does not copy the column roles from "regr", "classif" or "unsupervised". The packages mlr3spatial, mlr3cluster, mlr3forecast and mlr3proba create new task classes and copy the column roles.