Message from discussion make-random-state
From: RG <rNOSPA...@flownet.com>
Subject: Re: make-random-state
Date: Sat, 12 Feb 2011 17:09:00 -0800
Organization: Amalgamated Widgets Unlimited
References: <firstname.lastname@example.org> <rNOSPAMon-C4E2C8.email@example.com> <firstname.lastname@example.org> <rNOSPAMon-9531BC.email@example.com> <rNOSPAMon-66CB67.firstname.lastname@example.org> <email@example.com>
Content-Type: text/plain; charset=UTF-8
X-Trace: news.albasani.net 3NSy13KSSVI36AmRAnUZvvm0DvWh//Ub6MQb618A69txx1tAC4JwQgH6RyK9BNrKT/KKRpo1bX8MSVglQAEm1t6+gw6N8avKF7tExzzKSfRE2a+VVnJTFZeEsHotG20/
NNTP-Posting-Date: Sun, 13 Feb 2011 01:09:00 +0000 (UTC)
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
> 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
> > 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:
> > > (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.