phadej
commented
3 years ago newQCGen uses newSMGen
See https://hackage.haskell.org/package/splitmix-0.1.0.1/docs/System-Random-SplitMix.html
-- | Initialize SMGen using system time.
initSMGen :: IO SMGen
-- | Derive a new generator instance from the global SMGen using splitSMGen.
newSMGen :: IO SMGenI suspect that you call initSMGen somewhere, when you should call newSMGen. Or you use completely separate processes.
I do plan to make initSMGen to use some other sources of randomness
(like process id), but unfortunately base doesn't expose anything like
that so I'd need to write some C / JS code (Windows, GHCJS).
(I could hack some solution to read e.g. /dev/urandom on Linux, like tf-random does but I'd like to have proper solution on Windows and GHCJS too).
PeterRugg
We run several instances of QuickCheck in parallel. Recently we noticed that the parallel runs were all producing exactly the same counterexample, and on further investigations, exactly the same tests. Between versions 2.12.something and 2.13.2 this issue materialised, and is still present in 2.14.1. It seems that the default RNG (with GHC) has switched to SMGen, which seeds its RNG with the current POSIX time, in seconds! I would argue that this is not expected behaviour, so ideally QuickCheck would override the seed, or at the very least warn users in the documentation not to run multiple instances in parallel without paying attention to seeding. It could also be argued that this is an issue with SMGen so should be bumped further up the chain.