mb706

My assumption is that the `"encode"` `PipeOp` creates a column that is named `..row_id`, which confuses mlr3 since it is in some way a reserved column name.

Thanks! Apparently the problem is that bootstrapping uses some rows repeatedly, which somehow breaks with mlr3's assumption that row_ids are unique values. Minimal example: ```r library("mlr3") library("mlr3pipelines") options(mlr3.debug=TRUE) resample(tsk("iris"), po("pca")...

thanks! I will look into what is breaking the pkgdown pages...

I'm keeping this issue open as a reminder, I hope I get around to fixing this the next week.

> features that are important in multiple filters are "really important" That is an interesting idea, though I wonder whether the "correct" solution would rather be to have some kind...

```r FilterCombination = R6Class("FilterCombination", inherit = Filter, filters = NULL, initialize = function(filters) { super$initialize(id = "filtercombination", task_type = filters[[1]]$task_type, task_properties = Reduce(intersect, map(filters, "task_properties")), feature_types = Reduce(intersect, map(filters, "feature_types")),...

We should also think about how / where to represent the resulting information about pipeops and their edges.

My thoughts about things to consider, in random order: * with some operations it may make more sense to save just the `$state` and not the result. Then during `$train()`...

It would still be useful where we are using non-data.table backends. But it would also be a bit difficult, so this has low priority for now.

The bug for `classif.randomForest` in particular seems to be that it puts names on its predictions, and gives the `NA` prediction a `NA` name, which `cbind` in `makePrediction` trips over....