You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it stands, Gen programs draw random bits from the global entropy store. Going forward some control over the random seed is required --- for debugging, reproduciblity, and independence of Gen code from other libraries.
The granularity of entropy control is a design choice. Some possibilities include:
Continue using global seed which is set using Random.seed!(n)
pros: approach requiring least work
cons: unpredictable, no separation, harder to reproduce/debug results.
Furnish each Gen method that makes random choices with an (optional) a formal parameter prng
pros: composes easily, reproducible, predictable, modular, adds minimal API complexity, each random procedure becomes deterministic given its inputs.
cons: needs implementation and design
Design a special Monadic construct for the RandomSeed
pros: potentially more transparent to the user / designer of Gen library
cons: Julia does not have good native support for Monadic computation
Design a single global entropy source for Gen only
pros: less complex than 2 and 3, separates Gen from other libraries.
cons: less modular, and should check if/how to implement such an object in Julia.
The text was updated successfully, but these errors were encountered:
I have been exploring the possibility of switching from Turing to Gen for some of my modeling tasks since it seems a lot more flexible.
Unfortunately, I have to say that I am quite shocked by this design choice to rely on the global RNG. It's standard practice in most Julia packages that involve random sampling and/or stochastic behavior for the RNG state to be included as a parameter (option 2 above). Is there any possibility on having this changed any time soon? I am not sure that I can use the package without this since it makes it much harder to maintain reproducibility when using other packages that also require access to some RNG state.
I am not sure if @fsaad is still working on this project, so maybe @ztangent or @alex-lew could weigh in?
As it stands, Gen programs draw random bits from the global entropy store. Going forward some control over the random seed is required --- for debugging, reproduciblity, and independence of Gen code from other libraries.
The granularity of entropy control is a design choice. Some possibilities include:
Random.seed!(n)
prng
The text was updated successfully, but these errors were encountered: