ExactGP.predict and viGP.predict produce inconsistent shapes about gpax HOT 8 OPEN

I guess the predict method should just always output predictive mean and variance. Then we can have another method specific to HMC-based GPs that returns samples from the HMC posterior.

from gpax.

In fact, we can have .sample_from_posterior() method for all GPs that it will output samples of the shape (M, N, len(X_new)). For the HMC-based GPs, M is equal to the number of HMC posterior samples and for SVI-based GPs M is equal to 1.

from gpax.

Happy to attempt a fix if you'd like.

from gpax.

In the beginning, both ExactGP and viGP used to output identical shapes. However, while y_sampled in ExactGP makes sense since each sample comes from a different HMC sample with kernel hyperparameters, the y_sampled in viGP is sampled from the same single point estimate of the kernel hyperparameters, which makes it pretty noisy. Hence, for practical purposes, viGP returns the predictive variance values directly.

That said, there is certainly an "asymmetry" between fully Bayesian and variational inference tools currently available. I need to think a bit more about how to address it from the design point of view.

from gpax.

@ziatdinovmax I see what you're saying but ultimately doesn't it make more sense from a design standpoint to have a common interface? It's going to make building tools on top of what you already have really difficult if each of the GP's predict method returns something different.

IMO making this really clear in the docs but implementing the consistent method is the way to go. That way, a GP that inherits some base ABC has totally known behavior when calling predict (which naturally will make e.g. building the campaigning library much easier).

from gpax.

@matthewcarbone - adding it to the v0.3 'milestone' per our discussion

from gpax.

@ziatdinovmax yup sounds good. To be clear this would actually be a backwards-incompatible change (technically), since the shape of the predict method would change. Should we make such a change, or should we add a new method which returns a consistent shape between the GP methods?

from gpax.

Perfect, I really like the idea of sample_from_posterior().

from gpax.