Initializing Stan Model object with random_seed - all interfaces should use 3-arg constructor


Investigated bug, which reports that in rstan, RNG functions called from the transformed data block are always using the same seed value of 0, even when the random seed is overtly specified. cmdstan has the same problem.

This is due to the fact that the stan model object has both a 2-arg and 3-arg constructor. The 3-arg constructor takes an instantiated boost rng object; the 2-arg constructor instantiates such an object with seed 0.

I put a fix in for cmdstan - we need something similar for rstan and we should check all other interfaces - pystan, etc.


Thanks for tracking that down. Would you mind creating issues for RStan and PyStan and linking back to the suggested fix?




Further discussion raises the following questions:

  • do we want to keep the feature allow RNG in transformed data block?
  • per the above formulation, “it should use the overall seed, but not the chain”, would it make sense to change the Model 3-arg constructor to accept the seed instead of an RNG object?
  • should we file a new issue to fix the generated code so that the 2-arg constructor will try to generate a random seed instead of using 0?


I missed out on previous discussion of this feature - it seems like we want any randomly generated data in the transformed data block to be the same for all chains, correct?