Groups | Search | Server Info | Login | Register

Groups > comp.lang.c > #396570

Re: srand(0)

Show all headers | View raw

Michael S <already5chosen@yahoo.com> writes:

> On Wed, 07 Jan 2026 08:41:25 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> 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.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 08:41 -0800
  Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-08 01:06 +0200
    Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:26 -0800
      Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-03 16:37 +0200
        Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:47 -0800
          Re: srand(0) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-18 11:21 +0000
            Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 10:01 +0100
              Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-19 14:33 -0500
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 20:47 +0100
                Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-20 16:01 -0500
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-21 11:09 +0100
              Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-19 14:39 -0800
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-20 09:16 +0100
                Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 08:32 -0500
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 16:05 +0100
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-23 19:59 +0200
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 20:06 +0100
                Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 15:24 -0500
                Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-24 07:08 +0100
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-24 10:24 +0100
                Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-26 19:13 +0100

csiph-web