Proposal: Move 'split' into a separate class in System.Random

Bryan O'Sullivan bos at serpentine.com
Wed Sep 15 01:39:00 EDT 2010


On Tue, Sep 14, 2010 at 4:44 PM, Thomas DuBuisson <
thomas.dubuisson at gmail.com> wrote:

> The "split" routine in the RandomGen seems to be a sore spot for some
> people and is perceived to have few users (even as a percentage of
> RandomGen users).


Actually, it's worse than that: there's no statistical basis for believing
that the split operation is sound. It is sure to introduce correlations
between the forked generators, and depending on the particular PRNG in
question and the mixing used to perform split, this may result in a fatal
degradation of the quality of the random numbers generated.

While I understand the appeal of split, it is completely unsafe to use as it
stands. At the very least, in a new typeclass, its type needs to be amended
to a signature like this:

   - split :: g -> (Integer,g,g)

where the Integer term returned is an approximation to the period of the
newly split PRNGs. At that point, you at least get some sort of caveat
emptor that you're rapidly running out of entropy when you perform repeated
splits, and both implementors and users have less reason to treat split like
a magic box that brings forth unspecified goodness without consequences.

I realise that breaking up the typeclass like this will break existing code,
but I think it's safest to make a blanket assumption that all existing code
that uses split is already broken.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100915/eac7526c/attachment.html


More information about the Libraries mailing list