Skip to content

Including VarNames in sampler states, etc. #2511

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

Open
penelopeysm opened this issue Mar 18, 2025 · 0 comments
Open

Including VarNames in sampler states, etc. #2511

penelopeysm opened this issue Mar 18, 2025 · 0 comments
Labels
roadmap Turing.jl meta issues

Comments

@penelopeysm
Copy link
Member

penelopeysm commented Mar 18, 2025

Many things in the Turing ecosystem assume that parameters have a form of Vector{<:Real}. We currently tend to do a lot of vi[:] and vi = unflatten(vi, params) to convert between this vector-of-real and a VarInfo.

However, this representation leads to information loss in many places. See e.g.

TuringLang/DynamicPPL.jl#833

Sometimes we attempt to use a NamedTuple, but even that is not fully safe because NamedTuples are indexed by Symbols and not VarNames. This leads to issues like

TuringLang/DynamicPPL.jl#814
TuringLang/MCMCChains.jl#470
TuringLang/DynamicPPL.jl#702

To this end I've been thinking for a while now about changes to AbstractMCMC. It's also come up in discussions with @yebai and @mhauru. This is quite tough because it's one of the lowest-level packages in TuringLang and everything directly or indirectly depends on it.

I'm opening this issue here to collect some thoughts on it and will edit it slowly. Please bear with me, it's hard to formulate sensible thoughts on this topic, and even harder to write them down in a clear way.

Related:

TuringLang/AbstractMCMC.jl#156

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
roadmap Turing.jl meta issues
Projects
None yet
Development

No branches or pull requests

1 participant