Skip to content
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

Attach varname_to_symbol mapping to Chains #2078

Merged
merged 6 commits into from
Sep 12, 2023

Conversation

torfjelde
Copy link
Member

After TuringLang/DynamicPPL.jl#534 in DynamicPPL.jl, attaching a dict-like mapping from VarName to Symbol (as represented in the Chains) allows a much improved experience when working with Model and Chains together, e.g. generated_quantities that can handle things like Cholesky variates.

@torfjelde
Copy link
Member Author

So I was just looking at this one myself, and I don't think upping the DPPL version should fix this. This PR should have been functional on it's own.

@@ -133,10 +134,9 @@ function AbstractMCMC.bundle_samples(
le = getlogevidence(samples, state, spl)

# Set up the info tuple.
info = (varname_to_symbol = OrderedDict(zip(varnames, varnames_symbol)),)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make this inclusion optional? Forcing it could be annoying for serialization of the chains, etc. @yebai

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we skip this information while serializaing chains? I think we might want to carry such information in chains by default so functions like predict/generated_quantities can work.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we skip it in serialization, then those methods won't work after deserialization anyways 😕

And yes I agree it should be enabled by default, but I was also thinking it would be useful to provide a way to disable it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason why we can't serialise/deserialise VarName?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can, but it means that you no longer can do using MCMCChains; deserialize(...) but you need to have done using Turing first. IMO this is quite annoying 😕

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VarName is defined in AbstractPPL, which is lightweight. Can we make MCMCChains depend on AbstractPPL?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially in the longer run, but I don't think we should do that when MCMCChains doesn't use any functionality from AbstractPPL.

@github-actions
Copy link
Contributor

github-actions bot commented Sep 9, 2023

Pull Request Test Coverage Report for Build 6130928900

  • 0 of 14 (0.0%) changed or added relevant lines in 3 files are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage remained the same at 0.0%

Changes Missing Coverage Covered Lines Changed/Added Lines %
ext/TuringOptimExt.jl 0 1 0.0%
src/mcmc/emcee.jl 0 5 0.0%
src/mcmc/Inference.jl 0 8 0.0%
Files with Coverage Reduction New Missed Lines %
src/mcmc/emcee.jl 1 0.0%
Totals Coverage Status
Change from base Build 6077120878: 0.0%
Covered Lines: 0
Relevant Lines: 1449

💛 - Coveralls

@codecov
Copy link

codecov bot commented Sep 9, 2023

Codecov Report

Patch and project coverage have no change.

Comparison is base (c0c8130) 0.00% compared to head (0b92472) 0.00%.
Report is 1 commits behind head on master.

❗ Current head 0b92472 differs from pull request most recent head c35b041. Consider uploading reports for the commit c35b041 to get more accurate results

Additional details and impacted files
@@          Coverage Diff           @@
##           master   #2078   +/-   ##
======================================
  Coverage    0.00%   0.00%           
======================================
  Files          21      21           
  Lines        1447    1449    +2     
======================================
- Misses       1447    1449    +2     
Files Changed Coverage Δ
ext/TuringOptimExt.jl 0.00% <0.00%> (ø)
src/mcmc/Inference.jl 0.00% <0.00%> (ø)
src/mcmc/emcee.jl 0.00% <0.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@torfjelde
Copy link
Member Author

Okay, so I can't actually reproduce the error from the tests 😕

But I've now made it optional to include the varname_to_symbol mapping, so it will be possible for users to opt-out of this inclusion if they prefer. I think that should be good enough 👍

Project.toml Outdated Show resolved Hide resolved
@yebai yebai merged commit 8d8416a into master Sep 12, 2023
5 of 11 checks passed
@yebai yebai deleted the torfjelde/attach-varname-to-symbols-to-chain branch September 12, 2023 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants