[Haskell-cafe] Mersenne-random and standard random API

Aleksey Khudyakov alexey.skladnoy at gmail.com
Thu Feb 9 13:09:48 CET 2012


On 09.02.2012 15:32, Jerzy Karczmarczuk wrote:
> Aleksey Khudyakov :
> 1. Mersenne Twister, AND congruential generators AND the Marsaglia
> stuff, all use some kind of "seed", all are stateful. There are no
> miracles. Just look the agressive monadization, the form of defaultSeed,
> etc. within MWC.hs, before saying that this generator doesn't rely on
> some global state.
>
I think you are missing the point here. Surely all PRNG carry some state 
around. But both StdGen and mwc-random (and likely many others)
allow to have many generators at once (for use in different threads)

mersenne-random is just wrapper around vastly impure library (as
documentation says) and allows only one genrator per program.
This is why I said it uses *global* state


> 2. In the standard generator stuff the state is stored in IoRefs and is
> not "copied". Did Aleksey ever look inside the sources of these
> generators? In any case, the seed changes after each generation, and
> must be stored somewhere.
>
No. It doesn't and cannot

 > data StdGen
 >  = StdGen Int32 Int32

If generator state is stored in IORef it's not possible to implement
`next :: g → (Int,g)'. To do something useful with it one have to
go to IO monad but we can't. So state have to be copied.



> 3. The API question is a conventional one. People who are really
> unhappy, may make their own interfaces, or give such a mini-project as a
> students' assignment, instead of weeping that the library is lousy and
> should be ignored. E. g., I wanted random numers in some purely
> functional, lazy context, and I didn't want the existing interface ; I
> manufactured a lazy stream interface, and that was all. "Look Ma!: no
> global state..."
>
Usually. But sometimes it's not possible to implement some algorithms
for particular API. For example if PRNG rely on in-place array updates
it cannot implement Random type class.



> 4. L'Ecuyer signalled some 15 years ago that MWC generators introduce
> some bias on the most significant bits (complementary MWC are safer).
> This is less annoying that the last bits periodicity of simple
> congruential generators, but for SOME Monte-Carlo it may be harmful.
>
Thank you for reminder. I wanted to read their paper for some time.



More information about the Haskell-Cafe mailing list