Random Number Update

Tue Jan 24 15:55:10 UTC 2017

Carter,

I obviously didn’t explain myself very well. We can decouple removing the “bad” RNG from the replacement of it with a “good” RNG. As I thought I said, any new RNG should have the same status as every other RNG and then people can choose; there is no “blessed” RNG. It seems simple (to me at any rate) to decouple these.

More power to your elbow on creating an RNG but I don’t think there should be anything “official” about it. I’ll say it again: I don’t think there should be a random v2 but a random-foobar where foobar is your algorithm.

What do you see sub-optimal about deprecating something that is clearly broken?

I believe I have done my bit for the Haskell Community in trying to resolve what is a tedious situation. I suggest we await the view of the Core Libraries Committee assuming they still see this as part of their scope and take it from there.

Dominic.

> On 24 Jan 2017, at 15:33, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> Dominic, if you want to remove yourself from maintainer hood that's cool. 
> 
> I'm keen on finishing up my random v2 release which is a much improved breaking Change.  
> 
> I spent part of my holiday this year working on it. 
> 
> Dominic: I'm confused and surprised by your email after we had a one hour phone chat about this topic last week.  
> 
> I'm disappointed you are still raising concerns I addressed and explained to you last week. 
> 
> Random v2 is in flight. You are welcome to stop being involved. 
> 
> On Tue, Jan 24, 2017 at 10:19 AM Adam Bergmark <adam at bergmark.nl <mailto:adam at bergmark.nl>> wrote:
> On Tue, 24 Jan 2017 at 14:36 Dominic Steinitz <dominic at steinitz.org <mailto:dominic at steinitz.org>> wrote:
> I wanted to give an update on the status of random numbers in Haskell.
> 
> 
> 
> 
> 
>  1. It is well known that the random number generator package
> 
> 
>     https://hackage.haskell.org/package/random <https://hackage.haskell.org/package/random> gives unexpected
> 
> 
>     results.
> 
> 
>  2. Most people do *not* use it. I believe
> 
> 
>     https://hackage.haskell.org/package/mwc-random <https://hackage.haskell.org/package/mwc-random> is a popular choice
> 
> 
>     but developers are free to use e.g. Mersenne Twister, PCG
> 
> 
>     (Permuted Congruential Generator), TF (ThreeFish) and many others.
> 
> 
>  3. Approximately 2 years, I made a proposal to replace the algorithm
> 
> 
>     within random (https://hackage.haskell.org/package/random <https://hackage.haskell.org/package/random>) with
> 
> 
>     that used by tf-random
> 
> 
>     (https://hackage.haskell.org/package/tf-random <https://hackage.haskell.org/package/tf-random>) which is used by
> 
> 
>     QuickCheck. In summary, the response to this was that someone
> 
> 
>     should do more research with the result that nothing happened.
> 
> 
>  4. In the meantime, random
> 
> 
>     (https://hackage.haskell.org/package/random <https://hackage.haskell.org/package/random>) is *no longer* a core
> 
> 
>     library. It's just a library with the same status as
> 
> 
>     e.g. mwc-random. However, it has one difference: it uses the name
> 
> 
>     for its module: "System.Random". Other RNGs use
> 
> 
>     "System.Random.MWC", "System.Random.PCG", "System.Random.Mersenne"
> 
> 
>     etc.
> 
> 
> 
> 
> 
> As a maintainer of random
> 
> 
> (https://hackage.haskell.org/package/random <https://hackage.haskell.org/package/random>), my proposal now is to
> 
> 
> deprecate all of it.
> 
> 
> 
> 
> 
> I am not clear what the policy is on namespace usage. Could every RNG
> 
> 
> use the module name "System.Random"? Or is this somehow reserved? If
> 
> 
> the latter then I propose that *nothing* uses this name and that all
> 
> 
> RNGs should add a suffix indicating which algorithm they use.
> 
> They *could* use the same namespace but I don't recommend it. If someone depends on two of these packages they would have to use PackageImports. Tools such as doctest break if a package db has module conflicts, even if only one of the packages is listed as a dependency.
>  
> Cheers,
> Adam
> 
> 
> 
> 
> 
> 
> I note that the Haskell Platform contains tf-random so users of this
> 
> 
> will still be able to generate (better) random numbers.
> 
> 
> 
> 
> 
> If someone comes along in the future, as I hope they do, and
> 
> 
> implements e.g. Guy Steele's splitmix algorithm then this can occupy
> 
> 
> the name "System.Random.Splitmix" and have the package name
> 
> 
> "random-splitmix".
> 
> 
> 
> 
> 
> The advantages of doing this are:
> 
> 
> 
> 
> 
>  1. Neophyte (and experienced) Haskellers do not accidentally use an
> 
> 
>     RNG which gives unexpected results.
> 
> 
>  2. No-one will any longer be able to write blogs or papers about this
> 
> 
>     embarrassing aspect of Haskell.
> 
> 
> 
> 
> 
> I believe the co-maintainer of random
> 
> 
> (https://hackage.haskell.org/package/random <https://hackage.haskell.org/package/random>), Carter Schonwald, has a
> 
> 
> different view on this matter but it is best he speaks for himself
> 
> 
> rather than me imperfectly trying to reflect his thinking.
> 
> 
> 
> 
> 
> Dominic Steinitz
> 
> 
> dominic at steinitz.org <mailto:dominic at steinitz.org>
> 
> 
> http://idontgetoutmuch.wordpress.com <http://idontgetoutmuch.wordpress.com/>
> 
> 
> 
> 
> 
> _______________________________________________
> 
> 
> Libraries mailing list
> 
> 
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> 
> 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> 
> 
> 
> 
> _______________________________________________
> 
> Libraries mailing list
> 
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/d9e4677e/attachment.html>