mlrMBO
mlrMBO copied to clipboard
mlr-org
reread proposePointsDIB
I still don't understand the code behind the DIB completely. Did it get obfuscated with time or does it do something hidden?
-
Here we create n control objects all containing essentially the same as the control object itself, because the control object itself already has the DIB Criterion and because of
user.lambda = TRUEno modifications are done. - Now z is a list with control objects and different lambda values. Why do we need these lambda values?
- Here we take the copy of the control object (that has not changed) and we still don't change it.
So: Why all this trouble if we don't change the control object?
Ah damn,
@berndbischl and me talked about that the code seems to be buggy there, but we forgot to create an issue :(
When we implemented SMS-EGO, we had several possibilities how to propose multiple points in one iteration. One of them was to use different lambda-values for each proposed point. Moreover, we talked about decreasing the lambda-value during the optimization. (As you can still read in the comments.) In the end we decided to do neither of these, but unfortunately we did not clean up the code.
Here we create n control objects all containing essentially the same as the control object itself, because the control object itself already has the DIB Criterion and because of user.lambda = TRUE no modifications are done.
thats not true, we need to copy the control objects and set propose.points = 1 in them, so we can run single point proposal for each of them.
what is bad is this:
- createRandomControls has a bad name. it should be createMultipleSinglePointControls
- if user.lambda = TRUE, no random lambdas should be created or returned (but NULL instead)
and:
- the infill crit does not need to be in the signature of createMultipleSinglePointControls. its already as an object in "control"