mlrMBO
mlrMBO copied to clipboard
CMAES infill opt should allow integer parameter optimization
Performing mbo over integer parameter spaces with infill optimization "cmaes"
ps = makeParamSet(
makeNumericParam("q", lower = -1, upper = 2),
makeIntegerParam("v", lower = -2, upper = 3)
)
des = generateDesign(n = 7, par.set = ps)
des$y = c(1.20, 0.97, 0.91, 3.15, 0.58, 1.12, 0.50)
ctrl = makeMBOControl()
ctrl = setMBOControlInfill(ctrl, opt = "cmaes")
opt.state = initSMBO(par.set = ps, design = des, control = ctrl, minimize = TRUE, noisy = FALSE)
proposePoints(opt.state)
gives error
Error in cmaesr::cmaes(fn, start.point = start.point, monitor = NULL, :
CMA-ES only works for objective functions with numeric parameters.
it would be nice of MBO to allow this and perform rounding instead.
As I mentioned: Rounding afterwards is generally a bad idea in MBO since we don't know whether the acq values are better for ceil
or floor
.
There is even a paper on it that claimed this "realization" as a novelty when we already always did it correct in focussearch
.
I think it was this one: https://arxiv.org/abs/1805.03463
If I remember correctly there is some other infill opt that does perform rounding, though (I forgot which one)
Ah ok I just read your response to #476. I assume performing rounding is not that much of a problem if the integer range is large. For small integer ranges I guess you could choose to do rounding before the surrogate evaluation to simulate a step function to the infill optimization function.
If you are sure you don't want to do rounding you can close this.
I assume performing rounding is not that much of a problem if the integer range is large.
Let's put it into these words: If the function is more or less well behaved (i.e. not too jumpy) it should be okay to round.
I would accept a PR but would not bother to implement it myself.
Workaround is to have continuous parameters with a round() trafo