George Russell wrote:
> 
> Personally I have only one gripe with the Random class in Standard Haskell;
> this is that it provides too much functionality.
> In general I think you can only have two of the following 3:
> (1) good random numbers
> (2) speed
> (3) small state
> For example the Mersenne Twister is very very good and fast but has huge
> state (several kilobytes), see
>    http://www.math.keio.ac.jp/~matumoto/emt.html
> and there is even a Haskell implementation.

Nice to see my humble effort recognized.  I don't really think of ~2.5k
as all that huge, but I agree it's a lot bigger than what you normally
see in a simple PRNG.  Of course you get a much better semblance of
randomness because of it.

> But the current Haskell implementation forces you to have small state, and
> so you must have a slow generator.

I don't think that's really true.  If I understand it correctly, the
state can be any type; it doesn't have to fit in, say, an Int or other
small type.  I think the Mersenne Twister could be implemented as an
instance of Random.RandomGen.  The only thing is I don't really know the
best way to implement "split" for MT.

>  You don't really need this.  In most
> applications, if you need to get at the state at all, you only need to
> do it pretty rarely.

Yes, and the current interface provides randomIO and randomRIO for those
who don't want to have to pass the RandomGen instance around.  The cost
is they have to use the IO monad.

>  The following interface would suffice.  I agree it
> would be slightly yucky if you wanted to create lots of random values in
> a structure like a tree, because every function generating a substructure
> would have to be an action.  In GHC or Hugs, it would be neater if most of these
> functions were ST RandomGen or something like that.

I think we should allow people to pass the RandomGen around if they
choose to, and not force them into the IO monad.  I do agree that the ST
monad would be useful also as an alternative to IO, but only as an
addition to the current interface.  randomST and randomRST could be
provided as parallel functions to randomIO/RIO.  There would also have
to be a setRandomST function to set the RandomGen instance initially.

Cheers,
Matt Harden

Reply via email to