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

Restructure SMBO #55

Closed
mlindauer opened this issue Sep 20, 2016 · 4 comments
Closed

Restructure SMBO #55

mlindauer opened this issue Sep 20, 2016 · 4 comments

Comments

@mlindauer
Copy link
Contributor

Hi,

I would like to propose the following restructuring. In particular, the smbo class is right now responsible for too much stuff.

  • extra module for initial design
  • a smac-builder class which plugs all stuff together (right now in __init__ of smbo)
  • new entries to the runhistory should be only added in ExecuteTARun.start

btw: we have some methods in the BaseSolver which we never use, e.g., init_last_iteration, from_iteration, save_iteration and create_save_dir. Should we delete these?

Best,
Marius

@mlindauer mlindauer changed the title Restructure Modules Restructure SMBO Sep 20, 2016
@mfeurer
Copy link
Contributor

mfeurer commented Sep 20, 2016

Hi,

  • sounds very good to me.
  • whether we need a builder class I'm not sure. What would be the advantage of such a class? An empty __init__method? There is a discussion about this issue here.
  • sounds okay to me.

I think we don't use the BaseSolver at all at the moment. With this restructure we could move some parts to the BaseSolver and easily implement ROAR? Otherwise, we might also remove the base solver?

@mlindauer
Copy link
Contributor Author

whether we need a builder class I'm not sure. What would be the advantage of such a class? An empty __init__method? There is a discussion about this issue here.

Right now, the smbo class (which is not named smac) plugs together a lot of stuff. For example, the smbo class does not really need to know the TAE since only the intial design and the intensification issues TA runs.

I don't think that __init__ would be empty afterwards, since needs indeed some other objects, such as runhistory2epm or acquistion_func.

Maybe it would be over-engineered to add a builder class. I don't know.

With this restructure we could move some parts to the BaseSolver and easily implement ROAR?

Yes, this would be the next step.

@mfeurer
Copy link
Contributor

mfeurer commented Sep 20, 2016

Good point, the SMBO class doesn't need to know about the TAE. But if we have a builder, it should be responsible for creating the whole object, thus the init should be empty afterwards. What about the following to still keep it simple:

  1. have a builder object or function, which creates the whole SMBO object. This should not be visible to the everyday user.
  2. have a scipy.optimize-like interface which creates an SMBO object and runs SMBO. This should be used by the everyday user.

I'm also not sure if it would be overengineering, but it would certainly make unit tests easier if we add more options for the user.

@mlindauer
Copy link
Contributor Author

ok, sounds good. I will start to implement it.

mlindauer pushed a commit that referenced this issue Sep 22, 2016
* add facade package 
* add smac facade
* use utils.constants everywhere
* FIX minimal cost for log-cost has to be larger than 0
@mfeurer mfeurer closed this as completed Sep 30, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants