-
Notifications
You must be signed in to change notification settings - Fork 218
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
Refactoring VarName: new indexing scheme #484
Labels
Comments
Ps. I have attempted to enumerate all clashing name cases. However, there might be cases that I'm not aware. Please suggest any special cases that can potentially break the proposed naming scheme. |
For sanity checks, we might want to store the domain constraints of each parameter and verify them during replaying. |
Closed by #965 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At the moment, Turing internally stores and index parameters using two different naming schemes
This causes a lot of issues, e.g.
Chain
can't handle dynamic dimentionality [BNP] Bayesian Nonparametrics project #370 [Chain] flatten fails with different random variables in samples #386VarInfo
==>Chain
is not reversible Save model and sampler as fields of Chain #269These issues can be resolved together with a consistent naming scheme used by all data structures such as
Chain
,VarInfo
and inference algorithms. One possible naming scheme isBoth
VarInfo
andChain
can internally useunique_compiletime_id:counter
as their index. At the same time, we can also support the followingThis indexing scheme supports stochastic control flows (e.g. conditional, loops). It can also support compositional modelling #139 since var names don't clash with each other even when
mdemo
is called by another model.Related issues: #456
@trappmartin @xukai92 @emilemathieu
The text was updated successfully, but these errors were encountered: