Random Number Update

Wed Jan 25 12:47:09 UTC 2017

I’ll try and address the points.

1. I proposed a low cost solution as advocated by Sven and Henrik about 2 years ago, that of using tf-random. This was rejected because apparently better RNGs might exist. Now as we all know there is no such thing as the best RNG. My reasoning for tf-random was that if it were good enough for QuickCheck then it would certainly be good enough for naive users. A case of the best driving out the good? Not that best exists in this case.

2. QuickCheck were bitten very hard!

3. 
> Prelude> import System.Random
> Prelude System.Random> let dieRoll = fst . randomR (1,6) . mkStdGen :: Int -> Int
> Prelude System.Random> map dieRoll [1..20]
> [6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6,6]

4. In addition to the problems adumbrated above, random also has a range
> Prelude System.Random> newStdGen >>= return . genRange
> (1,2147483562)

which makes it fail even testu01’s SmallCrush if used naively.

random *may* work in certain cases but I would strongly advise against using it when there are so many other packages without the above problems. I would also add that for e.g. MCMC it is often very hard to see if something is working or not working because of the Monte Carlo noise; something apparently working does not necessarily validate a particular RNG.

I can’t say I agree with the reasoning that it is better to carry on using something that could be giving incorrect results silently rather than breaking things so that people can take action.

Anyhow as I have already said I feel I have done my bit for the Haskell Community. I agree with Carter that this is out of scope for the Core Libraries Committee. I wish you all luck and will step down from being maintainer.

> On 25 Jan 2017, at 11:26, libraries-request at haskell.org <mailto:libraries-request at haskell.org> wrote:
> 
> Send Libraries mailing list submissions to
> 	libraries at haskell.org <mailto:libraries at haskell.org>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
> or, via email, send a message with subject or body 'help' to
> 	libraries-request at haskell.org <mailto:libraries-request at haskell.org>
> 
> You can reach the person managing the list at
> 	libraries-owner at haskell.org <mailto:libraries-owner at haskell.org>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Libraries digest..."
> 
> 
> Today's Topics:
> 
>  1. Re: Selection Monad (Jakub Daniel)
>  2. Add Zero and One to Data.Functor (mirroring V1, U1)
>     (Baldur Blöndal)
>  3. Re: Random Number Update (Sven Panne)
>  4. Re: Random Number Update (Henning Thielemann)
>  5. Re: Random Number Update (Andreas Abel)
>  6. Re: Random Number Update (Henrik Nilsson)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 24 Jan 2017 17:23:58 +0000
> From: Jakub Daniel <jakub.daniel at gmail.com <mailto:jakub.daniel at gmail.com>>
> To: Eric Mertens <emertens at gmail.com <mailto:emertens at gmail.com>>
> Cc: libraries at haskell.org <mailto:libraries at haskell.org>
> Subject: Re: Selection Monad
> Message-ID:
> 	<CACaCNTSj5T0GnGkWgk_VO8vaL4dZYao16QUTCvYMXvsAyUw1oQ at mail.gmail.com <mailto:CACaCNTSj5T0GnGkWgk_VO8vaL4dZYao16QUTCvYMXvsAyUw1oQ at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Eric,
> 
> Just to clarify, my question was not about endorsing another library but
> rather extending the ones currently maintained by the committee with
> definition of a notion closely related to what is already contained in the
> libraries. It just so happens that Edward Kmett implemented the notion in a
> standalone library. However to me it does not make much sense to include
> ContT but not SelT (currently under the name Search) in the core libraries,
> despite their connection. I understand if this does not change the answer
> though.
> 
> Best Regards,
> Jakub Daniel
> 
> 
> 
> On Tue, 24 Jan 2017 at 17:39 Eric Mertens <emertens at gmail.com <mailto:emertens at gmail.com>> wrote:
> 
>> Hi Jakub,
>> 
>> The core libraries committee helps maintain libraries that are already
>> critical to the Haskell ecosystem. It doesn’t select new libraries to be
>> recommended to users. It’s possible that the search package is a hidden gem
>> that more people need to know about. To accomplish that people will need to
>> write software using it, market it with blog posts, and bring it up in
>> discussions.
>> 
>> Best Regards,
>> Eric Mertens
>> 
>> On Jan 24, 2017, at 5:57 AM, Jakub Daniel <jakub.daniel at gmail.com <mailto:jakub.daniel at gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I apologize in case this is not the right place to bring this
>> question/proposal up. Some time ago I stumbled upon the Selection Monad [1]
>> (also referred to as Search from the search package on hackage). Its
>> relation to the Continuation Monad and the usefulness demonstrated in [1]
>> made me wonder whether it would be nice to include Selection Monad in the
>> core libraries along the Continuation Monad (in mtl and transformers) with
>> all the business of selections attaining continuations. I can imagine the
>> pattern to be too little recognised to justify such an addition, yet the
>> theoretical connection to the Continuation Monad seems to be an interesting
>> one and worth being addressed.
>> 
>> Best,
>> 
>> Jakub Daniel
>> 
>> [1] Jules Hedges. *Monad transformers for backtracking search*. In *Proceedings
>> of MSFP 2014. *https://arxiv.org/abs/1406.2058 <https://arxiv.org/abs/1406.2058>
>> 
>> _______________________________________________
>> 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>
>> 
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/630bc9cc/attachment-0001.html <http://mail.haskell.org/pipermail/libraries/attachments/20170124/630bc9cc/attachment-0001.html>>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 24 Jan 2017 19:17:31 +0000
> From: Baldur Blöndal <baldurpet at gmail.com <mailto:baldurpet at gmail.com>>
> To: Haskell Libraries <libraries at haskell.org <mailto:libraries at haskell.org>>
> Subject: Add Zero and One to Data.Functor (mirroring V1, U1)
> Message-ID:
> 	<CAK9DwL8-6GdfPWza_sNpRfi5eQ+KE8H_0Wc0WCfAK9WrHEfv_A at mail.gmail.com <mailto:CAK9DwL8-6GdfPWza_sNpRfi5eQ+KE8H_0Wc0WCfAK9WrHEfv_A at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> Deadline of 2 weeks.
> 
> Original discussion: ⁽¹⁾
> 
> data Zero a
> data One  a = One
> 
> Same definitions as in ‘trivia’ package,⁽²⁾
> if a consensus is reached we can update
> the documentation for Free:⁽³⁾
> 
> “Free Zero” is isomorphic to Identity.
> “Free One” is isomorphic to Maybe.
> 
> ⁽¹⁾ https://ghc.haskell.org/trac/ghc/ticket/13177 <https://ghc.haskell.org/trac/ghc/ticket/13177>
> ⁽²⁾ https://hackage.haskell.org/package/trivia <https://hackage.haskell.org/package/trivia>
> ⁽³⁾
> https://hackage.haskell.org/package/free-4.12.4/docs/Control-Monad-Free.html <https://hackage.haskell.org/package/free-4.12.4/docs/Control-Monad-Free.html>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/3945e7ae/attachment-0001.html <http://mail.haskell.org/pipermail/libraries/attachments/20170124/3945e7ae/attachment-0001.html>>
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 24 Jan 2017 20:45:04 +0100
> From: Sven Panne <svenpanne at gmail.com <mailto:svenpanne at gmail.com>>
> To: Thomas Murphy <amindfv at gmail.com <mailto:amindfv at gmail.com>>
> Cc: libraries <libraries at haskell.org <mailto:libraries at haskell.org>>, dominic at steinitz.org <mailto:dominic at steinitz.org>
> Subject: Re: Random Number Update
> Message-ID:
> 	<CANBN=ms6-tDjJE4x-QbR5DX862xg6cFeMpW-M0PD+mQog=YQHA at mail.gmail.com <mailto:CANBN=ms6-tDjJE4x-QbR5DX862xg6cFeMpW-M0PD+mQog=YQHA at mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
> 
> 2017-01-24 18:33 GMT+01:00 <amindfv at gmail.com <mailto:amindfv at gmail.com>>:
> 
>> Carter, can you outline how random v2 compares to v1?
>> 
> 
> Whatever will be done, I think it would be good to keep the 'random'
> package alive, probably just by re-exporting one of the better RNGs,
> perhaps with a thin shim to keep the API identical. Yes, this would somehow
> "bless" one of the RNGs, but this is not important: The important thing is
> avoiding breakage in the ecosystem, keeping tutorials, books etc. valid.
> People who know what they are doing can easily pick the right RNG for their
> needs and/or quickly adapt their code, but I guess for lots of stuff having
> just *some* RNG under the traditional package name/module name is more than
> enough.
> 
> Just my usual backwards-compatibility-rant... ;-)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170124/e0d26476/attachment-0001.html <http://mail.haskell.org/pipermail/libraries/attachments/20170124/e0d26476/attachment-0001.html>>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 24 Jan 2017 21:53:48 +0100 (CET)
> From: Henning Thielemann <lemming at henning-thielemann.de <mailto:lemming at henning-thielemann.de>>
> To: Dominic Steinitz <dominic at steinitz.org <mailto:dominic at steinitz.org>>
> Cc: libraries <libraries at haskell.org <mailto:libraries at haskell.org>>
> Subject: Re: Random Number Update
> Message-ID: <alpine.DEB.2.02.1701242144080.7413 at sputnik>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> 
> On Tue, 24 Jan 2017, Dominic Steinitz wrote:
> 
>> 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.
> 
> I have used the plain old System.Random exclusively for years now and did 
> not encounter any problems, but I also did not watch for them. I used 
> System.Random for Markov chains, audio noise generation, randomized 
> algorithmic music, board game computer opponents etc. I'd like to keep a 
> default random generator for the many cases where I don't care about the 
> precise algorithm. That said, I got used to some randomized synthesized 
> sounds and randomized melodies such that I already noticed changes in the 
> random generator implementation.
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 25 Jan 2017 11:43:29 +0100
> From: Andreas Abel <abela at chalmers.se <mailto:abela at chalmers.se>>
> To: Henning Thielemann <lemming at henning-thielemann.de <mailto:lemming at henning-thielemann.de>>, Haskell
> 	Libraries <libraries at haskell.org <mailto:libraries at haskell.org>>
> Subject: Re: Random Number Update
> Message-ID: <29c97717-2946-6b8d-f458-a495c74e9232 at chalmers.se <mailto:29c97717-2946-6b8d-f458-a495c74e9232 at chalmers.se>>
> Content-Type: text/plain; charset="utf-8"; format=flowed
> 
>> I got used to some randomized synthesized
>> sounds and randomized melodies such that I already noticed changes in
>> the random generator implementation.
> 
> Can't be very random, if you can get used to it, no?
> :)  [Couldn't resist].
> 
> On 24.01.2017 21:53, Henning Thielemann wrote:
>> 
>> On Tue, 24 Jan 2017, Dominic Steinitz wrote:
>> 
>>> 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.
>> 
>> I have used the plain old System.Random exclusively for years now and
>> did not encounter any problems, but I also did not watch for them. I
>> used System.Random for Markov chains, audio noise generation, randomized
>> algorithmic music, board game computer opponents etc. I'd like to keep a
>> default random generator for the many cases where I don't care about the
>> precise algorithm. That said, I got used to some randomized synthesized
>> sounds and randomized melodies such that I already noticed changes in
>> the random generator implementation.
> -- 
> Andreas Abel  <><      Du bist der geliebte Mensch.
> 
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
> 
> andreas.abel at gu.se <mailto:andreas.abel at gu.se>
> http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 25 Jan 2017 11:44:49 +0000
> From: Henrik Nilsson <Henrik.Nilsson at nottingham.ac.uk <mailto:Henrik.Nilsson at nottingham.ac.uk>>
> To: libraries at haskell.org <mailto:libraries at haskell.org>
> Subject: Re: Random Number Update
> Message-ID: <58888FB1.8090300 at exmail.nottingham.ac.uk <mailto:58888FB1.8090300 at exmail.nottingham.ac.uk>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi,
> 
> On 01/24/2017 07:45 PM, Sven Panne wrote:
>> Whatever will be done, I think it would be good to keep the 'random'
>> package alive, probably just by re-exporting one of the better RNGs,
>> perhaps with a thin shim to keep the API identical. Yes, this would
>> somehow "bless" one of the RNGs, but this is not important: The
>> important thing is avoiding breakage in the ecosystem, keeping
>> tutorials, books etc. valid. People who know what they are doing can
>> easily pick the right RNG for their needs and/or quickly adapt their
>> code, but I guess for lots of stuff having just *some* RNG under the
>> traditional package name/module name is more than enough.
> 
> I couldn't agree more.
> 
> Good (pseudo) random number generators are very important, and the
> effort people like Dominic and Carter have put in is deeply appreciated.
> Thanks!
> 
> However, a simplistic generator is much better than code breakage and
> no generator. Users who don't pose the question about what
> generator is used under the hood are unlikely to be bitten very hard by
> a simplistic one. But they would be bitten hard if there isn't any or if
> the API changes.
> 
> I've used the present one for games and the like, and they work OK for
> that. I've also used them in an implementation of Metropolis-Hastings 
> (for Bayesian inference) (albeit not that much) and I at
> least broadly got the results I expected.
> 
> Best,
> 
> /Henrik
> 
> 
> 
> 
> 
> 
> 
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it. 
> 
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
> 
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> 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>
> 
> 
> ------------------------------
> 
> End of Libraries Digest, Vol 161, Issue 36
> ******************************************
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/20170125/ab2e7fd6/attachment-0001.html>