Update for DynamicPPL 0.39 #2715
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Turing.jl documentation for PR #2715 is available at: |
penelopeysm
force-pushed
the
py/dppl039
branch
from
24142ee to
507d814
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The main change in DPPL 0.39 is OnlyAccsVarInfo and faster evaluation.
This PR uses fast evaluation in MCMC sampling where it can. MCMC sampling mostly works as can be seen from the tests.
There are a few outstanding issues:
(1) MCMCChains no longer stores an overall
chain.logevidencefieldThe reason is because we now use the
bundle_samplesmethod in DynamicPPL, which has no way of reliably determining the log-evidence from the transition. If we wanted to fix this, we would have to add agetlogevidencefunction in AbstractMCMC.I personally don't consider this a problem. The reason why log-evidence used to be stored was because chains did not provide enough information for people to calculate this themselves (specifically, chains only stored logp, not loglikelihood). Now that
chn[:likelihood]contains the likelihood, it's trivial for people to calculate this themselves.(2) Chains aren't consistent between
:lpand:logjointBecause I messed this up: TuringLang/DynamicPPL.jl#1140 So some samplers will have one and other samplers the other. This needs to be fixed upstream, but should be a very trivial patch.
(3)The optimisation interface hasn't been updated in this PR
I think we should merge or reject #2708 first.