st--
@willtebbutt could you summarise the remaining issues in here ?
Reviving this discussion, another question is where should the computation/optimisation go? E.g. for SparseVariationalApproximation we need to optimise to find the optimal q(u), and currently this is left as an...
> "Approximate" is a bit inaccurate in my opinion since it does not indicate that we are working with a bound... My point was that in some cases it really...
Should we define `approx_log_evidence(::FiniteGP, ...) = logpdf(...)`?
I'm just thinking, how about moving VFE & DTC out of AbstractGPs and into ApproximateGPs?
You're right, we can just construct `LatentGP(ApproxPosteriorGP(...), ...)` - e.g. as follows (excerpted from https://github.com/JuliaGaussianProcesses/ApproximateGPs.jl/pull/59/files#diff-2581bfaaa21433d043e4343891c3547bbba68f31c35416bd6fcc9773e256c673R333): ```julia function AbstractGPs.posterior(la::LaplaceApproximation, lfx::LatentFiniteGP, ys) cache = # ... f_post = ApproxPosteriorGP(la, lfx.fx, cache) return...
How about adding a constructor along the pseudocode lines of ```julia function update_latent_posterior(latent::Union{LatentGP, LatentFiniteGP}, new_f_posterior::ApproxPosteriorGP) return LatentGP(new_f_posterior, latent.lik, latent[.fx].Σy end ``` to hide the implementation detail for now?
Oh, the other part that's missing is that the only API implemented for `LatentGP` so far is `rand`, but of course most of the time we do actually want to...
> Probably we should just make the LatentFiniteGP have all four fields that it needs (latent process, inputs, jitter, and likelihood) to make things more explicit and to avoid depending...
@simeonschaub: in case you hadn't spotted it in the related issue yet, https://github.com/JuliaDiff/ChainRulesCore.jl/issues/462#issuecomment-925593793