AbstractGPs.jl icon indicating copy to clipboard operation
AbstractGPs.jl copied to clipboard

(Do not merge) **BREAKING** Remove LatentGP

Open willtebbutt opened this issue 4 years ago • 4 comments

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.

willtebbutt avatar Nov 09 '21 21:11 willtebbutt

Codecov Report

Merging #243 (675e575) into master (89afecb) will decrease coverage by 0.05%. The diff coverage is n/a.

Impacted file tree graph

@@            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 data Powered by Codecov. Last update 89afecb...675e575. Read the comment docs.

codecov[bot] avatar Nov 09 '21 21:11 codecov[bot]

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

st-- avatar Nov 10 '21 06:11 st--

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.

willtebbutt avatar Nov 10 '21 13:11 willtebbutt

Is this still something worth pursuing?

simsurace avatar Mar 10 '24 19:03 simsurace