Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: srand(0) Date: Tue, 03 Feb 2026 05:26:47 -0800 Organization: A noiseless patient Spider Lines: 74 Message-ID: <864inyj6ug.fsf@linuxsc.com> References: <10ib0ka$3cgil$1@dont-email.me> <10ibava$2sora$1@dont-email.me> <10ibcub$25ihi$2@dont-email.me> <10ibu81$2sora$2@dont-email.me> <10ibvrm$25ihh$2@dont-email.me> <20251222204538.00003fc2@yahoo.com> <10iekvr$pa8n$1@paganini.bofh.team> <20251224000824.00005ce7@yahoo.com> <86tswxnznu.fsf@linuxsc.com> <20260108010601.00002085@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 03 Feb 2026 13:26:52 +0000 (UTC) Injection-Info: dont-email.me; posting-host="72e789f1a61a439ff5daaffc25398413"; logging-data="1520319"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MtvLjGK4ybu5EbAQtE3+lVdWM6EcwNLM=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:GW9MNarPgbNNhMePRlA6JZRF2r4= sha1:3++GFZdz25F4MlZ9bGLgXOM6n5U= Xref: csiph.com comp.lang.c:396570 Michael S writes: > On Wed, 07 Jan 2026 08:41:25 -0800 > Tim Rentsch wrote: > >> Michael S writes: >> >>> On Tue, 23 Dec 2025 17:54:05 -0000 (UTC) >>> antispam@fricas.org (Waldek Hebisch) wrote: >> >> [...] >> >>>> There is a paper "PCG: A Family of Simple Fast Space-Efficient >>>> Statistically Good Algorithms for Random Number Generation" >>>> by M. O?Neill where she gives a family of algorithms and runs >>>> several statistical tests against known algorithms. Mersenne >>>> Twister does not look good in tests. If you have enough (128) bits >>>> LCGs do pass tests. A bunch of generators with 64-bit state also >>>> passes tests. So the only reason to prefer Mersenne Twister is >>>> that it is implemented in available libraries. Otherwise it is >>>> not so good, have large state and needs more execution time >>>> than alternatives. >>> >>> I don't know. Testing randomness is complicated matter. >>> How can I be sure that L'Ecuyer and Simard's TestU01 suite tests >>> things that I personally care about and that it does not test >>> things that are of no interest for me? Especially, the latter. >> >> Do you think any of the tests in the TestU01 suite are actually >> counter-indicated? As long as you don't think any TestU01 test >> makes things worse, there is no reason not to use all of them. >> You are always free to disregard tests you don't care about. > > Except that it's difficult psychologically. > The batteries of test gains position of of authority in your mind. > Well, may be, you specifically are resistant, but I am not. Nor is > Melissa O'Nail, it seems. > > To illustrate my point, I will tell you the story about myself. > Sort of confession. > [very large portion] I have read through your whole posting several times, and also looked through your other postings in this thread. Despite my efforts I am still not sure what you think or what you're trying to say. Let me put it as a question. Do you think there is a good and objective test for measuring the quality of a PRNG? If so what test (or tests) do you think would suffice? Here "quality" is meant as some sort of numeric measure, which could be a monotonic metric (as in "the larger the number the higher the quality") or just a simple pass/fail. If you don't think there is any such test, how do you propose that PRNGs be evaluated? > One important point that I seem to figure out recently is that the > only practical way to produce both solid and very fast PRNG that > adheres to standard language APIs with 32-bit and to somewhat smaller > extent 64-bit output, is to use buffering. I.e. most of the time > generator simply reads pre-calculated word from the buffer and only > ones per N iterations runs an actual PRNG algorithm, probably in a > loop, often in SIMD. In order for this approach to be effective, > buffer can't be particularly small. 32 bytes (256 bits) appear to be > an absolute minimum. The buffer and counter that manages buffering, > are parts of the generator state. That alone sets a practical minimal > limit on the size of generator and diminishes significance of the > difference between PRNGs with "algorithmic" state of 64 bits, 128 bits > or even 256 bits. I understand what you're saying. These concerns are orthogonal to the question of the quality of the numbers generated, which for the purposes of this conversation is all I'm interested in.