Some PipeOps need their own hash function

[sebffischer]

The two learners below have the same hash although they should not. The problem is that PipeOpLearner inherits the hash function from PipeOp which does not take the hash of the learner that is passed during construction into account.

library(mlr3verse)
#> Loading required package: mlr3

at1 = auto_tuner(
  learner = lrn("regr.rpart"),
  measure = msr("regr.mse"),
  term_evals = 10,
  tuner = tnr("random_search"),
  resampling = rsmp("cv", folds = 3)
)

at2 = auto_tuner(
  learner = lrn("regr.rpart"),
  measure = msr("regr.mse"),
  term_evals = 10,
  tuner = tnr("random_search"),
  resampling = rsmp("holdout")
)

g1 = as_learner(ppl("robustify") %>>% at1)
g2 = as_learner(ppl("robustify") %>>% at2)

g1$hash
#> [1] "631881f0a872501a"
g2$hash
#> [1] "631881f0a872501a"

^{Created on 2023-05-21 with reprex v2.0.2}

[sebffischer]

I think in general the hash function of the pipeop should check whether the PipeOp has non-standard construction arguments and if it does it should throw an error so one does not inherit a wrong hash method

[mb706]

To the degree that the auto_tuner does not do its own hashing properly there is nothing mlr3pipelines can realistically do.