<p dir="ltr">I actually think a bit more exploratory work and building up some testing and performance infrastructure in place are needed before doing any major version bump of randoms algorithm. </p>
<p dir="ltr">  Additonally theres a good chance we'll be having a gsoc student this summer who can help with this.   </p>
<p dir="ltr">Additionally, I will likely be able to put some work engineering time into exploring the algorithm choice. </p>
<p dir="ltr">Point being, I want the next major version bump of random to raise the bar on engineering for prng libraries.  So we have a bit of work to do first before we make a choice that forces  upgrades on the universe.  And we arent there yet</p>
<br><div class="gmail_quote">On Sat, Apr 4, 2015, 2:00 PM Dominic Steinitz <<a href="mailto:dominic@steinitz.org">dominic@steinitz.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hello All,<div><br></div><div>Having skimmed the literature, run some tests and benchmarks:</div><div><br></div><div><ul><li>The current System.Random is broken: <a href="https://github.com/haskell/random/issues/25#issuecomment-87423142" target="_blank">https://github.com/haskell/random/issues/25#issuecomment-87423142</a>. Furthermore, this is recorded in at least two published papers: <a href="http://dl.acm.org/citation.cfm?id=2660195" target="_blank">http://dl.acm.org/citation.cfm?id=2660195</a> and <a href="http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf" target="_blank">http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf</a>.</li><li>The tf-random package does not have this breakage and is based on good theoretical foundations.</li><li>In my tests tf-random performs better than System.Random.</li></ul></div><div><br></div><div>As a result of which, I am very much inclined to suggest we replace the code in System.Random with tf-random. Before doing any more work on this, I’d like to understand what the next steps should be.</div><div><br></div><div><ul><li>How much review should be carried out? I have no reason to doubt the implementors have done a great job but should someone (who?) review the code more formally. If so what would the process / tools be?</li><li>Tests in packages / applications may now fail as the (pseudo) random numbers will be different with this change. What should we do here? Alert folks (who and how?) that the may have to rebase their tests? Tell folks that 1.1 is deprecated and they should move to 2.0 (I think it’s right to indicate this is a completely new version)?</li><li>Are there any other steps?</li></ul><div><br></div></div><div>FYI: I did look at Guy Steele et al. but I don’t believe there is currently a Haskell implementation of it, probably ruling it out as possible solution in the medium term.</div></div><div style="word-wrap:break-word"><div><br><div>
<div>Dominic Steinitz</div><div><a href="mailto:dominic@steinitz.org" target="_blank">dominic@steinitz.org</a></div><div><a href="http://idontgetoutmuch.wordpress.com" target="_blank">http://idontgetoutmuch.wordpress.com</a></div>

</div>
<br></div></div></blockquote></div>