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

create convenient "entrypoints" for different MBO variants #138

Open
jakob-r opened this issue Jan 18, 2016 · 9 comments
Open

create convenient "entrypoints" for different MBO variants #138

jakob-r opened this issue Jan 18, 2016 · 9 comments
Assignees
Labels

Comments

@jakob-r
Copy link
Sponsor Member

jakob-r commented Jan 18, 2016

for example call ego(fun, ...) and no more control objects are needed for simple stuff.

@jakob-r jakob-r added this to the v0.1 milestone Jan 18, 2016
@berndbischl berndbischl changed the title create MBO helpefunctions create convenient "entrypoints" for different MBO variants Jan 18, 2016
@berndbischl
Copy link
Sponsor Member

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.

@berndbischl
Copy link
Sponsor Member

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?

@jakob-r
Copy link
Sponsor Member Author

jakob-r commented Jan 19, 2016

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?

@berndbischl
Copy link
Sponsor Member

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.

@jakobbossek
Copy link
Contributor

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.

@berndbischl
Copy link
Sponsor Member

The thing is:
We DEFINITELY want to do this. We are not discussing if we do this, but what API is the nicest approach.

@jakobbossek
Copy link
Contributor

I should read the entire log here and not just the last few postings I guess 😄

@jakob-r
Copy link
Sponsor Member Author

jakob-r commented Feb 17, 2016

I created a branch: You can compare here.
I suggest leaving the discussion here and just open the PR when it's really done.

@jakob-r jakob-r self-assigned this Apr 28, 2016
@jakob-r jakob-r added the later label May 24, 2016
@jakob-r
Copy link
Sponsor Member Author

jakob-r commented Jun 7, 2016

See PR #234

@jakob-r jakob-r removed this from the v0.1 milestone Oct 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants