Open Crown421 opened 1 year ago
Hmm. I see where you're coming from, but I'm reluctant to add redundant fields into the PosteriorGP
object. Is there a reason that it's hard to just keep the noise variance around in whatever your particular context is / a reason that it must go into the posterior object?
For this became an issue when using decoupled sampling/ getting a realization from the GP. I think it is much nicer to have all information needed to get a realization from the GP itself.
Carrying it around separately seems unnecessarily error-prone.
Ah, so you're trying to sample from the posterior at some points, and want samples + whatever noise the observations were made under? Could you provide a toy example of what you're trying to do?
Not quite. The decoupled sampling/ matheron's rule works of generating samples from the noise distribution, so Normal(0, Sigma_y)
.
At least that is the case with the standard implementation
(from https://arxiv.org/pdf/2002.09309.pdf)
I can't think of a way to do this without knowing the observation noise.
Ahhh, I see what you mean. I agree that you need access to the noise model when doing the pathwise sampling stuff. I think I also agree that the right time to introduce the approximations involved is when you've got hold of a PosteriorGP
object (since the pathwise sampling stuff is really introducing an approximate posterior).
I'd definitely be happy to review this PR.
I noticed that once you have a
PosteriorGP
, it is no longer possible to recover the noise level that was given in the construction of theFiniteGP
.My quick fix for this would be to just add
Sigma_y
to thedata
field in thePosteriorGP
. I have this currently implemented in a local copy, and am happy to make a quick PR.