Restructure the control object about mlrmbo HOT 14 CLOSED

Regarding the general problem of ctrl being too huge: 100% Agreed.

I very much like your proposal to keep the huge thing internally but to have restricted constructors with separate help pages!

Can you make a proposal? If there is need for discussion, please write instead of wasting time!

from mlrmbo.

Or maybe Jakob could work on this?
Jakob can you comment?

Please also note that roxygen2 now has templates, to reduce copy-paste crap!

from mlrmbo.

We should think of 3 or 4 meaningful groups of params, which can be seperated in extra constructors. I would suggest:

• main Params (like minimize, number.of.targets, ...), should stay in the main function
• infill options
• Multipoint - all single objective multipoint params, except propose.points. And we could check something like: This control object hast du be NULL if propose.points equals 1.
• Multicrit - same like Multipoint. At the moment this would contain only the parEGO params, but it will grow after I implementend smsEGO and moeadEGO
• Modell evaluation, like save.modell.at and resample.at
• Error handling

Doing this would be mainly copy-pasting code from the actual makeMBOControl function into new functions.

from mlrmbo.

A very meaningful split.
Just one remark: may be adding an extra group for parameters of noisy infill criteria. Here we also first have to check whether the noisy=TRUE in the main group.

from mlrmbo.

Maybe main, model eval and err handling is 1 group?

from mlrmbo.

I would've kept the "main" params in the "main" function and moved model eval and err handling to an extra function, but I agree that err handling an model eval could be one group.

from mlrmbo.

Groups:

• main
• single point infill + optmizer
• multipoint / single objective
• multiobjective

from mlrmbo.

ctrl = makeMBOControl(bla bla normal args)

ctrl = setMBOControlInfill(ctrl, crit = "ei", optimizer = "focussearch" )

Do not change internal structure of ctrl. It is still a big list.

from mlrmbo.

We REALLY need to make sure that from the groups / docs it is clear what param affects what.

These are LOGICAL groups of scenarios:

• single vs multi obj
• deterministic vs noisy
• single vs multi point

from mlrmbo.

Ok, I will split up the control object into the following groups:

• all infill.* stuff will be set with setMBOControlInfill(ctrl, ...)
• all multipoint.* stuff will be set with setMBOControlMultipoint(ctrl, ...)
• all the multi-criteria stuff (at the moment just the parego parameters) will be set with setMBOControlMulticrit(ctrl, ...)
  During this refactoring step, I will drop the infill and multipoint prefixes of the parameters, but keep the parego prefix, because - as Daniel mentioned - smsEGO and other multi-criteria algorithm may introduce some more parameters and we for sure do not want each algorithm to have its own setMBOControl... function.
  The remaining parameters will be set by a general makeMBOControl(...) function.

Note: We do not want to force the user to call all the setter methods even if he/she wants to keep the default settings. Therefore in the main object, I will call all of the specified setters without overriding the default values.

Agree?

from mlrmbo.

ok go

from mlrmbo.

Done. What's left is to check the documentation of the arguments, because we frequently address other arguments that now might not be arguments of the corresponding set... function.

from mlrmbo.

I dont care.

Put one sentence into every help page that one has to check the other control objects for those names too.

from mlrmbo.

Done.

from mlrmbo.