maybe add option to log y before modelling about mlrmbo HOT 21 CLOSED

Jakob, can you try to do this?

from mlrmbo.

Log transform y before fitting the model?

from mlrmbo.

yes, assume that for some functions it is easier to model logy than y.

actually we would like to learn that during optimization,
for now let the user simply decide it.

BEFORE you do anything, write down here how you proceed, regarding the most important changes.

from mlrmbo.

Ok, we allow log-transformation only for single-objective functions I guess. Therefore I would check this first. Moreover I would make the following changes:

• introduce a new logical control parameter log.y.before.modelling
• maybe indicate in print.MBOResult, that y values were log-transformed before modeling
• each time we evaluate the true objective function, check whether the resulting y value is negative. What to do in this case? Stop the process with an error?
• in makeMBOSingleObjTask check whether log.y.before.modelling is TRUE and log-transform the y.name column of the data frame

from mlrmbo.

I know, this is tagged as an enhancement and is hence not so important. Can you nevertheless comment my last post?

from mlrmbo.

You can start looking this now.

from mlrmbo.

introduce a new logical control parameter log.y.before.modelling

Ok. But lets try to keep names at least a bit shorter. Also we could make this more generic. Maybe have trafo.y as a string that selects a method.

maybe indicate in print.MBOResult, that y values were log-transformed before modeling

Ok

each time we evaluate the true objective function, check whether the resulting y value is negative.
What to do in this case? Stop the process with an error?

Yes. Throw error.

in makeMBOSingleObjTask check whether log.y.before.modelling is
TRUE and log-transform the y.name column of the data frame

Ok

from mlrmbo.

Ok. But lets try to keep names at least a bit shorter. Also we could make this more generic. Maybe
have trafo.y as a string that selects a method.

Ok, we can use mboTrafo functions for that as they are already implemented.

from mlrmbo.

How would an mbo call with y on log scale then look like?

from mlrmbo.

...
control = makeMBOControl(trafo.y = logTrafo())
res = mbo(obj.fun, par.set, learner = learner, control = control)

from mlrmbo.

Ok.
Can we rename the trafos to "trafoLog" so we can get them via command completion?

from mlrmbo.

ok

from mlrmbo.

Renamed the trafo function. Transformation of y now possible before modeling, but check for negative values is hardcoded and applied regardless whether transformation function required this check or not. Maybe we should allow our trafo functions to have a sanity check function as an attribute?

from mlrmbo.

I am looking at makeMBOTrafoFunction

1. Do not (mostly) use at_see_also. Use at_family in roxygen.

2. Having the check in the trafo is totally OK. But the warnings can be annoying.
   Have an option "error", "warn", "quiet"

3. You cannot do sqrt(< 0). Have a check there too.

from mlrmbo.

4. We do not need log and log10. Have an option "base", with default = 10.

from mlrmbo.

ok, I will add an option with values "error", "warn" and "quiet" to the trafo functions. The call to the selected trafo function will be parametrized with "error" before modeling y. This way the process will terminate if a negative value occurs. ok?

from mlrmbo.

I overworked the trafo functions. Trafo functions now have another argument handle.violations which defaults to "warn". In the case of transforming y values before modeling, we call the trafo function with handle.violations = "error".

from mlrmbo.

Added test. Works fine. Can I close this?

from mlrmbo.

How is "handle.violations" ever setzable from the outside? Shouldnt this be in the constructor of the trfo function?

Also: You never use it in the unit tests.

from mlrmbo.

Well, I thought this should be an internal thing. But you are right. Maybe it is better to make this a parameter of the trafo function.

from mlrmbo.

Done.

from mlrmbo.