EmuKit
Wrappers for GPflow and GPyTorch
Would be nice to have wrappers for other GP libraries and run a benchmark using the sample problems and acquisitions.
That is an interesting question, as to how many wrappers we want in Emukit. At first my thought was that we want very few, to show others "how it's done" while keeping the library clean and compact. From that perspective GPyWrapper should suffice, and if we want to benchmark against other libs, we can create wrappers for whatever we want without worrying about them going into core library.
But other point here would be that the more wrappers we have, the more people coming from various backgrounds can use emukit smoothly. So I am not so sure anymore. Anybody else has an opinion?
That's a good point. I'll elaborate a bit more on why I opened the issue.
I want to have wrappers for GPflow and and GPyTorch is because I would like to write a notebook to explicitly show how you can change the modeling back-end and reuse other parts of the library, in BO for instance. This is one of the core features that the library promises but we don't have an explicit example at the moment.
I guess that very specific wrappers should't go into the main library and can stay in the examples folder, but I don't see a big issue with having other generic wrappers as the one we have for GPy as soon as the interfaces are respected. Or is there anything I am missing?
Another way to talk about it is to define "specific". Do we need a wrapper for gaussian process to show to use it with emukit? Sure. Do we need a couple? In so, which libs to wrap? GPy, GPflow and GPyTorch , scikit-learn GPs, anything else? Where should we draw this line, if anywhere?
On the other hand, to we need to wrap BNN for same purpose? Most likely yes. Again, how many BNN implementations should have wrappers in emukit?
I am not saying we shouldn't wrap all of these libraries, maybe we should. But I am trying to encourage us to have a discussion about that.
Re: the encouraged discussion - it would be great to have more model wrappers. Various tricks and methods will likely be developed and can be reused, especially in the first contrasting model proposed by @javiergonzalezh .
If the concern is to keep emukit clean and compact, might these wrappers be developed and maintained in a separate amzn/emukit-models repository? Seems like isolating them to the examples directory is a pass at this compromise...
