-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVGP
deprecation not exact
#88
Comments
I think it'd be better to remove the SVGP(args...) = error(
"`SVGP(...)` is deprecated; use `SparseVariationalApproximation(Centered(), ...)` "*
"for retaining previous behaviour, or consider if you want to use "*
"NonCentered() [new default] instead."
) |
But isn't it an issue now that this is a bug and that should be solved before the next breaking release (your solution is nice but would be breaking |
My solution would be fixing a bug - the change from SVGP to SparseVariationalApproximation was already declared breaking. If anyone is actually using SVGP, and they rely on |
|
You can write @deprecate SVGP(fz, q) SparseVariationalApproximation(Centered(), fz, q) but then that won't add a deprecation for the struct, so also wouldn't be backwards compatible. Moreover, |
AFAIK this is on purpose since deprecatipn warmings slow down code massively. Eg, deprecations in a Turing model make it basically impossible to sample with the model if warnings are enabled. |
Actually, the type doesn't get aliased anyways, so doesn't make a difference. See #95. (Though personally I'd still prefer an explicit |
|
it doesn't work together with the constructor |
SVGP
simply redirects toSparseVariationalApproximation
, but theSVGP
default (and only implementation) wasCentered
representation, whereasSparseVariationalApproximation
defaults toNonCentered
. So it was actually a breaking change. Is there some way we can fix this?Originally posted by @st-- in #64 (comment)
The text was updated successfully, but these errors were encountered: