Path: g2news1.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!weretis.net!feeder4.news.weretis.net!news.albasani.net!rNOSPAMon
From: RG <rNOSPA...@flownet.com>
Newsgroups: comp.lang.lisp
Subject: Re: make-random-state
Date: Sat, 12 Feb 2011 17:09:00 -0800
Organization: Amalgamated Widgets Unlimited
Lines: 106
Message-ID: <rNOSPAMon-72480A.17090012022011@hello.network>
References: <ij5f38$c9g$2@news.eternal-september.org> <rNOSPAMon-C4E2C8.00144112022011@hello.network> <4d564903$0$1076$afc38c87@read01.usenet4all.se> <rNOSPAMon-9531BC.07595312022011@hello.network> <rNOSPAMon-66CB67.08273112022011@hello.network> <4d56d495$0$1069$afc38c87@read01.usenet4all.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net 3NSy13KSSVI36AmRAnUZvvm0DvWh//Ub6MQb618A69txx1tAC4JwQgH6RyK9BNrKT/KKRpo1bX8MSVglQAEm1t6+gw6N8avKF7tExzzKSfRE2a+VVnJTFZeEsHotG20/
NNTP-Posting-Date: Sun, 13 Feb 2011 01:09:00 +0000 (UTC)
Cancel-Lock: sha1:MB2Bl8BgPz5DDIuNXmEA9FnfLW8=
User-Agent: MT-NewsWatcher/3.5.1 (Intel Mac OS X)
Injection-Info: news.albasani.net; logging-data="hNhcSKBcQgS5Y4Yyvxi3yYmQppXdohfcDJfUvxq61cubu4MyVZ3tMTTQBiJI/LXrWc6cI9OLuEIIGg/SXlQ5CbX/oHdLWG9gYna2yfckXL+GsyrL2oGmeT96BfIAGtO8"; mail-complaints-to="ab...@albasani.net"

In article <4d56d495$0$1069$afc38...@read01.usenet4all.se>,
 Edmunds Cers <edmu...@laivas.lv> wrote:

> RG <rNOSPA...@flownet.com> writes:
> 
> > In article <rNOSPAMon-9531BC.07595312022...@hello.network>,
> >  RG <rNOSPA...@flownet.com> wrote:
> >
> >> In article <4d564903$0$1076$afc38...@read01.usenet4all.se>,
> >>  Edmunds Cers <edmu...@laivas.lv> wrote:
> >> 
> >> > RG <rNOSPA...@flownet.com> writes:
> >> > 
> >> > > You'll almost certainly get better quality results than whatever your 
> >> > > implementation has built in.
> >> > 
> >> > Why include this piece of FUD?
> >> 
> >> Because it's true.
> >
> > Let me expand on that a little.  There are good RNGs and bad RNGs.  
> 
> And there's your problem. RNGs are typically evaluated along three axes:
> 
> 1) their performance;
> 2) the apparent randomness of a sequence of produced numbers;
> 3) the suitability of the RNG for cryptographic applications.
> 
> There is no single standard of goodness and the second and third goals
> are conflicting with the first. You can (or could at least) get a faster
> RNG of the same "randomness" if you ignore the third requirement, for
> example.
> 
> There can certainly be reasons for using a library RNG instead of the
> built in one, like when you need a certain performance / randomness /
> cryptographic profile or just need to be able to share the state of the
> RNG between implementations (as might actually be required by the
> OP). But there is no reason to use a library RNG on principle, since the
> generators provided by the implementation should be good and well
> optimized.
> 
> > There are lot more of the latter than the former.  Designing an RNG is 
> > one of those things (like cryptography) that's very easy to get wrong.  
> > If you rely on an implementation's RNG you may or may not be getting a 
> > good RNG.  
> 
> Do you believe any implementation provides an in-house RNG? If what you
> meant was that there are many factors to consider when choosing a RNG,
> then you are right. I'd guess that most implementations would choose
> something that is good either along the performance or the randomness
> axis and ignore the cryptographic axis (unless it comes at a small
> penalty). And no better choice can be made by you either, until you
> actually know what you need.
> 
> > If you use the code I referenced then you are certainly getting a good
> > RNG (by currently known standards).  Since the code is portable and
> > open-source it is almost certainly less effort to just use it than to
> > determine whether or not your particular implementation has a good
> > RNG.
> 
> How do I know that the code you provide correctly implements the RNG it
> purports to implement? Also, its RANDOM is about 8 times slower on my
> CCL then the built in RANDOM. Plus, this provides an additional
> dependency to manage. Finally, will this still be the "best" RNG in twenty
> years? I'd expect implementations to change their RNG's as breakthroughs
> are made, whereas no support is promised for your library.
> 
> > Making such a determination is non-trivial.  It requires either
> > examining source code (and knowing what you're doing), contacting the
> > vendor, or running statistical tests, any of which is almost certainly
> > more effort than just downloading the single file containing the
> > mrg32k3a code and using it.
> 
> Yeah, but making this determination is also unnecessary for most
> tasks. And your library is *not* universally better than the provided
> RNGs (see above). I think your whole line of argumentation is based on
> FUD. In fact, you should first show that the RNGs used by the
> implementations *are* bad, for your argument to have any validity.
> 
> > But this is of course not *necessarily* true.  In CCL for example:
> >
> > ? (make-random-state)
> > #.(CCL::INITIALIZE-MRG31K3P-STATE ...
> >
> > That looks promising. On the other hand, in CLisp:
> >
> > [1]> (make-random-state)
> > #S(RANDOM-STATE
> >    #*0001000011110011000000010110011100111010001100111110000000001110)
> >
> > That, not so much.
> 
> So CCL apparently uses some variant of the multiple recursive generator
> (same family as your library), while ACL, CMUCL, SBCL and ABCL use the
> Mersenne twister which is very good on the performance and randomness
> fronts. What are those bad implementations using broken RNGs? CLISP?
> That's 64 bits of state you posted above, not nearly small enough to
> assume some problem.
> 
> All in all, I think your initial statement was _really_ FUD-ish. There are
> too many misconceptions about Lisp floating around as is, for lispers
> themselves to make new ones up from thin air.

Very well, I concede the point.

rg