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
I validated that my StepRng is working as expected using the same code as the example:
let sample:[u64;3] = rng.gen();assert_eq!(sample,[2,3,4]);
While the returned integers do increase by 1, as expected, I was under the impression that it would also result in a predictable, but non-constant outcome of choose(), as long as I set the increment value of the RNG to anything other than 0.
However, it looks like I'm always getting the first element of my slice back. This isn't terrible, but it would be nice if this wasn't the case, so I could rule out some situation where the RNG isn't actually used, and the business logic is wired to always return the first value of a slice, which would be undesired behaviour.
Most sampling algorithms assume the RNG result is evenly distributed over the whole u32 or u64 output space; several of our implementations actually give the high bits more significance than the low bits. Using StepRng with a small step will keep the u64 counter "small" for a long time, and since our gen_range primarily uses the high bits, it could be a long time before the result changes (depending on the output range).
Activity
JeanMertz commentedon Oct 7, 2018
Never mind me.
StepRngisn't supposed to be used for these situations. Instead, I can use a PRNG with a constant seed when testing the implementation.dhardy commentedon Oct 8, 2018
Most sampling algorithms assume the RNG result is evenly distributed over the whole
u32oru64output space; several of our implementations actually give the high bits more significance than the low bits. UsingStepRngwith a small step will keep theu64counter "small" for a long time, and since ourgen_rangeprimarily uses the high bits, it could be a long time before the result changes (depending on the output range).