st--

What would stop us from simply passing the inputs x directly to the likelihood object when calling it? The LatentFiniteGP already carries x with it, so we could extract it...

@willtebbutt your two examples seem inconsistent (and that's why I wanted to see some mock code usage!): in your first example, `f` is the concrete evaluation of the function at...

> ```julia > lik(x::MOInputIsotopicByOutput) = (f::AbstractVector{ MvNormal(f[1:N], map(exp, f[N+1:end])) > ``` Made me wonder if perhaps we could unify the two isotopic MO inputs into a single parametric type, so...

NB- `lgp.Σy` seems rather misleading; it's got nothing to do with y: could we more explicitly just call the field `jitter` instead?

What's the reason for not just having this within the GPLikelihoods package ?

Hm, on the one hand I agree it's nice if it's in the place as where it gets used - maybe the following is too hypothetical: I'm just wondering if...

In the new tests, could you separate out the terms, call it e.g. `dtc_posterior_mean = ... # see (ref) (eq. X)`? that'd be really helpful to make it easier to...

It's quite confusing that in the exact case, you call `posterior`, in the approximate case you call `update_posterior`....

In any case, should we add a `convert(Distributions.MvNormal, ::FiniteGP)`? I'd be happy with that:)

@rossviljoen @willtebbutt is this sufficiently resolved by #194 ?