Gen.jl icon indicating copy to clipboard operation
Gen.jl copied to clipboard

Determine policy for controlling entropy

Open fsaad opened this issue 6 years ago • 1 comments

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:

  1. 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.
  2. 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
  3. 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
  4. 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.

fsaad avatar Dec 06 '18 19:12 fsaad

Hi all,

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?

Thanks!

bgroenks96 avatar Feb 26 '24 17:02 bgroenks96