Well said, a lot of the tools that depend on a good quality RNG have migrated to tf random and friends. So a thoughtful time scale is very much the way to go On Mon, Apr 6, 2015, 4:50 PM Edward Kmett wrote:

If we're going to switch out algorithms completely then a first digit major version bump seems entirely warranted.

Pulling in tf-random's code entirely is definitely one way to move forward, and it has the benefit of being a relatively simple migration.

As for tf-random vs. trying out a port of Guy Steele's work to Haskell.

That is more a question of time and available engineering effort.

Do we take the short term win or look to see how much further performance we could eke out by going down Guy's path?

Given that tf-random is already there and working, I'd be inclined to take the longer path forward.

-Edward

On Sat, Apr 4, 2015 at 1:57 PM, Dominic Steinitz wrote:

...

Hello All,

Having skimmed the literature, run some tests and benchmarks:

- The current System.Random is broken: https://github.com/haskell/ random/issues/25#issuecomment-87423142 https://github.com/haskell/random/issues/25#issuecomment-87423142. Furthermore, this is recorded in at least two published papers: http://dl.acm.org/citation.cfm?id=2660195 http://dl.acm.org/citation.cfm?id=2660195 and http://publications.lib.chalmers.se/records/fulltext/ 183348/local_183348.pdf http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf . - The tf-random package does not have this breakage and is based on good theoretical foundations. - In my tests tf-random performs better than System.Random.

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.

- 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? - 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)? - Are there any other steps?

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.

Dominic Steinitz dominic@steinitz.org http://idontgetoutmuch.wordpress.com

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries