Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New mboContinue needed to allow changing strategies mid-stream #403

Open
zkurtz opened this issue Oct 5, 2017 · 1 comment
Open

New mboContinue needed to allow changing strategies mid-stream #403

zkurtz opened this issue Oct 5, 2017 · 1 comment

Comments

@zkurtz
Copy link

zkurtz commented Oct 5, 2017

If I understand the current mboContinue function correctly, it only allows you to finish a previously defined run according to some initial control settings. How hard would it be to generalize this to allow continuation (building on old results) while switching to a search strategy (new control object and/or new learner)? Here is a sketch of such a function, but it of course won't run as is:

#' @description continue search, building on previous run, but this time 
#' according to [potentially new and modified] learner and control  arguments
mbo_continue = function(run, objective, new_lrn, new_ctrl){
    history = as.data.frame(run$opt.path)
    new_run = mlrMBO::mbo(run
                          control = new_ctrl, 
                          learners = new_lrn)
    new_history = as.data.frame(new_run$opt.path)
    new_history = new_history[new_history$dob > 0,]
    new_run$history = rbind(history, new_history)
    return(new_run)
}

To clarify, it's not hard to build a wrapper that uses old history to define a new design object with precomputed values and then start a new search. The real challenge here is building such a wrapper that preserves all history from both runs in a cohesive way.

@jakob-r
Copy link
Sponsor Member

jakob-r commented Oct 9, 2017

Unfortunately it is a bit hard to do it now because of the way the history is saved. I am working heavily on related issues at the moment and I have the same things in mind.
For a more open way to acces MBO look at #397 (it even includes a vignette
You could access and modify elements of the opt.state with the $ operator. For other stuff you have to dive in deeper into the package. Therefore you could have a look at the project_coneptdrift branch which uses more flexible way to store the OptPath, so that subsetting like you have it in mind becomes more easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants