Restructure SMBO about smac3

[mfeurer]

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]

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]

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]

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