AbstractGPs.jl
AbstractGPs.jl copied to clipboard
(Do not merge) **BREAKING** Remove LatentGP
Summary
All of our work involving the LatentGP and friends type now resides in ApproximateGPs.jl. Moreover, literally nothing in this package uses that type. Given that we're going to need to iterate on the LatentGP type a bit (following last week's discussions about its shortcomings), I propose to move it to ApproximateGPs (see counterpart PR there).
Proposed changes
Move LatentGP and friends to ApproximateGPs.jl
- ...
What alternatives have you considered?
I considered not moving it, and trying to evolve the LatentGP abstractions while adding additional code to ApproximateGPs, but my feeling is that's going to hinder development, and force us to make lots of breaking releases of AbstractGPs (which are a bit of a pain for downstream packages to process, and are annoying if none of the change affect those packages).
Breaking changes
Removal of LatentGP. I doubt this will affect anyone but us, as I don't think anyone is using it.
Codecov Report
Merging #243 (675e575) into master (89afecb) will decrease coverage by
0.05%. The diff coverage isn/a.
@@ Coverage Diff @@
## master #243 +/- ##
==========================================
- Coverage 98.05% 98.00% -0.06%
==========================================
Files 10 9 -1
Lines 360 350 -10
==========================================
- Hits 353 343 -10
Misses 7 7
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update 89afecb...675e575. Read the comment docs.
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 longer run that'll make it harder to get it as a base for multiple packages - maybe someone else wants to implement some other approximations, wouldn't it then be nice if they could depend on just AbstractGPs? Or if someone wanted to do MCMC on a LatentGP model (I think that should be doable with just LatentGP? makes me think we ought to have a notebook for that :smile: )
Yeah, that's a good point, and I guess was the original motivation for having it in this package.
Lets leave this open -- I'm currently implementing a LatentGP that requires entire sample paths as part of some of my research, so I'm going to be proposing some changes to LatentGP. Lets see how that process goes, and revisit if it's truly awful. 🤞 it'll be fine.
Is this still something worth pursuing?