Open jakob-r opened 8 years ago
For every REASONABLE MBO variant we write a an easy to use function. We will have to reuse the control objects a little bit, I guess. The stuff which is set in makeMBOControl I think we still need?
And before we do this, we should carefully write down the API, so we are SURE we really make stuff easier and dont overcomplicate things.
Actually, it might be easier to simply have makeEGOControl? And do the dispatch via that? We can then also make use of "@inheritParams" from roxygen?
The reason behind a ego function is that we could also define the surrogate learner ourselves and increase simplicity. On the other hand: Why not both?
Both is just confusing for the user and too much too maintain. The reason I like the control object approach much better, is because we dont duplicate so much. An we can still define good defaults for the learner. But: Instead of arguing in the blind, lets just write down here, how both options would look like.
Did the same in ecr. I agree, that it is somehow a maintainence overload, but has some benefits as well especially in hiding the creation of the control object and offering a more "R-like" interface.
The thing is: We DEFINITELY want to do this. We are not discussing if we do this, but what API is the nicest approach.
I should read the entire log here and not just the last few postings I guess :smile:
I created a branch: You can compare here. I suggest leaving the discussion here and just open the PR when it's really done.
See PR #234
for example call
ego(fun, ...)
and no more control objects are needed for simple stuff.