Lennart Schneider

I think this could either be fixed in `mlr3pipelines` "manually" or we directly fix `mlr3::convert_task` which seems to cause the problem (i.e., during the trafo a new `Task` is created...

Cleaned this up. Currently has two parameters: * `filter_formula` (`formula` with only a rhs evaluating to `TRUE` or `FALSE` within the data of the `Task` indexing rows to keep) *...

> That argument for 'nacols" would also apply to other conditions to filter by, e.g. trying to filter if any of a number of features is 0 or negative. We...

> So this is supposed to filter out rows during predict time, right? Is there a way to keep track of what sample is being predicted, once a learner sees...

Hi @py9mrg, your approach above does not work out of the box because the `SDcols` hyperparameter of `PipeOpFilterRows` is set to `selector_all()` by default, and `selector_all()` called on a `Task`...

@py9mrg, @mb706 and I have to go over it and check whether the complete functionality is still within the scope of mlr3pipelines. Also, selecting targets via selectors is still an...

I guess if we want to be really flexible with respect to which `Resampling`s to include, there is no other way than also wrapping the `Resampling` as provided by the...

Some comments: Ideally we do not aggregate / deal with multiple (or none) predictions per `row_id` but rather have a `PipeOpAggregate` or something that operates on some meta info of...

some more comments: add `row_reference` to `task_col_roles`. `LearnerCV` then simply appends the row reference to the task and the aggregator/`PipeOpJoin` then handles it

I just did a reiterate which I summarize here: - `PipeOpLearnerCV` now wraps any `Resampling` and simply returns the predictions. Due to the fact that some `Resampling ` methods may...