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

Taking stochastic control flow a bit more seriously #25

Closed
mohamed82008 opened this issue Jan 2, 2020 · 3 comments
Closed

Taking stochastic control flow a bit more seriously #25

mohamed82008 opened this issue Jan 2, 2020 · 3 comments

Comments

@mohamed82008
Copy link
Member

Currently, we support a variable number of random variables but only when the random variables are elements of an array that's always at least partially sampled. That is each "symbol" in the model is assumed to be visited every time you run the model. This is enough most of the time and indeed one can group together all optional parameters in a vector and use this method, however it fails to address models of the form:

@model demo(x) = begin
    a ~ Uniform()
    if a > 0.5
        b ~ Normal(a)
        x ~ Normal(b)
    else
        c ~ Uniform()
        x ~ Normal(c)
    end
end

Note that b and c will not always be "visited". The current VarInfo setup will therefore fail in those cases. One way to address this is to have an UntypedVarInfo stored inside the TypedVarInfo for previously unseen variable symbols. Then during the sampling, we can check at every iteration if there are new symbols sampled. If so, we create a new spl::Sampler whose spl.state.vi is an instance of the expanded TypedVarInfo. If we do this right, I think we will not be paying any penalty in the case where all the symbols are always visited, and we may need to pay only a small dynamic dispatch price per new symbol seen, keeping the remaining of the code type stable.

@phipsgabler
Copy link
Member

Can this be closed? Does the current design solve this?

@yebai
Copy link
Member

yebai commented Feb 3, 2021

This requires #188 to be merged, I think.

@yebai yebai pinned this issue Dec 16, 2021
@yebai yebai unpinned this issue Nov 2, 2022
@yebai
Copy link
Member

yebai commented Dec 19, 2024

#728 implemented an automated check for this issue leveraging JET.jl.

@yebai yebai closed this as completed Dec 19, 2024
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

No branches or pull requests

3 participants