<div class="gmail_quote">On Tue, Sep 14, 2010 at 4:44 PM, Thomas DuBuisson <span dir="ltr"><<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The "split" routine in the RandomGen seems to be a sore spot for some<br>
people and is perceived to have few users (even as a percentage of<br>
RandomGen users).</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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:</div><div><ul><li>split :: g -> (Integer,g,g)</li>
</ul></div><div>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.</div>
<div><br></div><div>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.</div></div>