st--
st--
> I have to say I find it quite confusing when it's good to add a type restriction because that'll prevent errors and when it's bad to add a type...
It's currently a rather slow notebook. For example, it seems rather inefficient that we have to compute `posterior(fx, y_train)` all over whenever we want to plot... isn't there some way...
This should prevent the overfitting issue, as discussed by Ober et al.
We were discussing having a concerted effort at giving us a nicer frontend for fitting GPs. Before we sit down and do that, let's discuss what should be in scope?...
AbstractGPs currently defines `elbo`, but other approximations (e.g. Laplace, EP) also provide approximations to the (log) marginal likelihood that can be used for hyperparameter optimisation. Would be great to have...
Get in touch with maintainers of packages that currently use other or their own GP implementations to see if they'd be interested in collaborating in making their package work with...
When preparing #240 I stumbled across having to pass both FiniteGP for input features `f(x)` and targets `y` to both `posterior` (for PosteriorGP) and `logpdf` (for log marginal likelihood). Maybe...
**Summary** Remove `_symmetric()` calls on user-provided matrices that should be pos-def (and hence symmetric) already, as discussed in https://github.com/JuliaGaussianProcesses/AbstractGPs.jl/pull/236#discussion_r738464168 **Proposed changes** We use `_symmetric()` to ensure we can compute cholesky...
The low-rank update is implemented for the `VFE` sparse approximation, but this should of course be just as easy for an exact `FiniteGP`.:)
~And/or should we have a separate LatentApproxPosteriorGP?...~