Will Tebbutt

Eurgh, yeah, you're probably right. This is very sad, but probably necessary for now.

I keep changing my mind on this. On the one hand, the name suggests that this is a good idea. On the other, VFE / DTC / FITC don't add...

Haha fair enough. If you didn't know it was there, we should probably just move it here.

> With these tests, we can identify a subjectively small but consistent discrepancy between my computationally naive test implementation and the package's implementation. Not sure if it is a bug...

Hmmm I actually don't think that we do have that lying around. Could you open an issue about it so that we don't forget it?

Thanks for opening an issue to discuss this -- very keen to have feedback and discuss the design with as many people as possible. > some more "high-level" functionality for...

> I fully second this. Some kind of consistent interface like that in Flux (with Flux.params, Flux.trainable) would be a nice goal to strive towards but as long as it's...

> 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)....

I was thinking about this again in the context of approximate inference. I think I would be in favour of adding a function called `log_evidence(::PosteriorGP)` and (something along the lines...

I forgot, we essentially have this: https://github.com/JuliaGaussianProcesses/AbstractGPs.jl/blob/09fa526bd25492fdd0e9b41b2c294f0afe8cab13/src/exact_gpr_posterior.jl#L38 If you call posterior on a `FiniteGP{