Possible issue with new RNG?

[andrjohns]

Description:

Not sure if this is a bug or just me doing things wrong, but it looks like the new RNG doesn't interact with the Math library in the same way - the return is always constant:

#include <iostream>
#include <stan/services/util/create_rng.hpp>
#include <stan/math.hpp>

int main() {
  using stan::math::normal_rng;
  stan::rng_t rng(0);
  std::cout << "stan::rng_t: "
            << normal_rng(5, 10, rng) << ", "
            << normal_rng(5, 10, rng) << ", "
            << normal_rng(5, 10, rng) << ", "
            << normal_rng(5, 10, rng)
            << std::endl;

  boost::ecuyer1988 rng2(0);
  std::cout << "boost::ecuyer1988: "
            << normal_rng(5, 10, rng2) << ", "
            << normal_rng(5, 10, rng2) << ", "
            << normal_rng(5, 10, rng2) << ", "
            << normal_rng(5, 10, rng2)
            << std::endl;
  return 0;
}

Gives:

stan::rng_t: 5, 5, 5, 5
boost::ecuyer1988: -4.52988, 8.12959, 2.12997, 5.78816

Current Version:

v2.35.0

[andrjohns]

Oh hold on - it looks like the issue is the 0 seed value. If I change the seed to 1 then all is good:

stan::rng_t: 0.0297492, 10.3881, -9.09565, -1.47649
boost::ecuyer1988: -4.52988, 8.12959, 2.12997, 5.78816

[bob-carpenter]

That sounds really dangerous---@mitzimorris and @SteveBronder should know if this is going to be an issue through Stan or CmdStan---we need to check somewhere that seeds aren't zero.

[andrjohns]

RStan will also need to update their handling for exposing RNG functions, since they default to a zero seed (FYI @bgoodri) - we were doing the same in cmdstanr, which is how I found this

[bgoodri]

I think that a seed of zero was working fine in the past.

[andrjohns]

I think that a seed of zero was working fine in the past.

Yep, but it will be a problem with the new RNG in Stan (boost::mixmax instead of boost::ecuyer1988) - see the example at the top of the issue

[SteveBronder]

Should we change it to check for zero as the seed and if it is just +1?

[bob-carpenter]

No, because then a user supplying 0 and a user supplying 1 get the same answer. It'd be better to add 1 to all the inputs, which just means whatever the max is will have to be one less.

[WardBrian]

I can't reproduce up at the cmdstan level - supplying seed 0 and id 0, I still get valid sampling behavior, no repeat draws

@andrjohns do you observe the bad behavior up at the cmdstan level? If so this is possibly an architecture issue or boost bug?

[WardBrian]

No, because then a user supplying 0 and a user supplying 1 get the same answer

Note that this was actually already the case with the previous rng in Stan

[andrjohns]

I can't reproduce up at the cmdstan level - supplying seed 0 and id 0, I still get valid sampling behavior, no repeat draws

@andrjohns do you observe the bad behavior up at the cmdstan level? If so this is possibly an architecture issue or boost bug?

Looks like it's definitely a Boost bug - reproduced on godbolt. I'll file an issue with Boost now

EDIT: upstream issue here: boostorg/random#104

[WardBrian]

The papers on the mixmax generator say the seed needs at least 1 nonzero bit. We have a bunch of extra bits to work with in the end, so we can definitely ensure that

[WardBrian]

Separate from the discussion on what's the best way to turn the user-supplied seed into an initialization for the pRNG, do we have an explanation for why this bug seems to not matter at the integration-test level?

E.g., why can I still get good samples from my model if I specify seed=0 id=0 at the moment.