Branching and Graph param sets, dependencies and tuning

[berndbischl]

we need to be able to ask a graph for its param set. obviously, for tuning.

now what happens if we do branching.
for every pipeop that follows after the branch (and before the unbranch)
its paramset is dependent now on the "selected" param of the brancher.

we basically, when we ask the graph for the PS, have to generate this on the fly, thru a toposrt, and then add the dependencies while we walk thru the graph.

this is unfortunately RATHER complex, and i would like to avoid this.
but with the current design i dont see how....

[mb706]

The easy (albeit a bit ugly) way is to hard-code into Graph that PipeOpBranch branches and PipeOpUnbranch unbranches, but what if the user wants to build his own multiplex?

A nicer way would be to query each PipeOp what kind of conditions it sends along each of its output channels. Every node (a) gets the disjunction of conditions of its input nodes as dependency and (b) sends this dependency along its own output nodes (possibly conjoined with its own conditions)

[mb706]

There is a problem here with the way paradox currently checks parameter feasibility. Suppose I have a pipeline branch -> [ scale, pca ] -> unbranch, and the dependencies get set correctly. Then whenever I switch the branch$param_set$selection parameter between scale and pca, I would also have to reset the parameters of the other pipeop in the same step.

[mb706]

Notes from duplicate #744 :

We should not need this:

https://github.com/mlr-org/mlr3book/blob/b16a689e4a93b8f5e1b6957c1e63f16ec8f8f6ae/book/chapters/appendices/solutions.qmd#L1324-L1329

see also

https://mlr-org.com/gallery/optimization/2021-03-11-practical-tuning-series-build-an-automated-machine-learning-system/

Maybe we can also avoid needing to declare dependencies here:
https://github.com/mlr-org/mlr3book/blob/b16a689e4a93b8f5e1b6957c1e63f16ec8f8f6ae/book/chapters/appendices/solutions.qmd#L1300-L1318