Re: Article of Melissa O'Nail

From	Michael S <already5chosen@yahoo.com>
Newsgroups	comp.lang.c
Subject	Re: Article of Melissa O'Nail
Date	2025-12-28 12:35 +0200
Organization	A noiseless patient Spider
Message-ID	<20251228123533.000062a2@yahoo.com> (permalink)
References	(7 earlier) <20251224000824.00005ce7@yahoo.com> <10iga40$11ds6$1@paganini.bofh.team> <20251224121211.00000e8f@yahoo.com> <20251228024431.00000016@yahoo.com> <10iqfpd$2g8io$1@paganini.bofh.team>

Show all headers | View raw

On Sun, 28 Dec 2025 05:38:55 -0000 (UTC)
antispam@fricas.org (Waldek Hebisch) wrote:

> Michael S <already5chosen@yahoo.com> wrote:
> > On Wed, 24 Dec 2025 12:12:11 +0200
> > Michael S <already5chosen@yahoo.com> wrote:
> >   
> >> On Wed, 24 Dec 2025 09:00:50 -0000 (UTC)
> >> antispam@fricas.org (Waldek Hebisch) wrote:
> >>   
> >> > Michael S <already5chosen@yahoo.com> wrote:    
> >> > > On Tue, 23 Dec 2025 17:54:05 -0000 (UTC)
> >> > > antispam@fricas.org (Waldek Hebisch) wrote:
> >> > >       
> >> > >> Michael S <already5chosen@yahoo.com> wrote:      
> >> > >> > On Mon, 22 Dec 2025 18:41:10 +0100
> >> > >> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >> > >> >         
> >> >     
> >> > > Also, the TestU01 suit is made for generators with 32-bit
> >> > > output. M. O’Neill used ad hoc technique to make it applicable
> >> > > to generators with 64-bit output. Is this technique right? Or
> >> > > may be it put 64-bit PRNG at unfair disadvantage?      
> >> > 
> >> > My point of view is that generator can be used to generate long
> >> > bistream.  Then you can cut the bitstream and get number of
> >> > desired size.  Good tests should check that such usage leads
> >> > to reasonable properties.  So, fact that one generator produces
> >> > 32-bit pieces and other produces 64-bit pieces should be
> >> > irrelevant to the test.
> >> >     
> >> 
> >> What you say is correct in few use cases. But there are many uses
> >> cases (in field of testing of numeric code, probably, most of them)
> >> in which "less random" LS bits are acceptable. 
> >> Not that I can see why it could be the case for MT19937-64, but it
> >> could apply to one of two of other 64-bit generators tested by
> >> O'Neill.
> >> 
> >>   
> >> > > Besides, I strongly disagree with at least one assertion made
> >> > > by O’Neill: "While security-related applications should
> >> > > use a secure generator, because we cannot always know the
> >> > > future contexts in which our code will be used, it seems wise
> >> > > for all applications to avoid generators that make discovering
> >> > > their entire internal state completely trivial."
> >> > > No, I know exactly what I am doing/ I know exactly that for my
> >> > > application easy discovery of complete state of PRNG is not a
> >> > > defect.      
> >> > 
> >> > O’Neill is not a prophet, ignore what she say it you think you
> >> > know better (which is probably the above).
> >> >     
> >> > > Anyway, even if I am skeptical about her criticism of popular
> >> > > PRNGs, intuitively I agree with the constructive part of the
> >> > > article - medium-quality PRNG that feeds medium quality hash
> >> > > function can potentially produce very good fast PRNG with
> >> > > rather small internal state.      
> >> > 
> >> > She seem to care very much about having minimal possible state.
> >> > That is may be nice on embeded systems, but in general I would
> >> > happily accept slighty bigger state (say 256 bits).  But if
> >> > we can get good properties with very small state, then why not?
> >> > After all looking at state and updating it takes code, so
> >> > small state helps with having fast generator.
> >> >     
> >> 
> >> Agreed.
> >>   
> >> > Concerning Mersenne Twister, she is not the only one to
> >> > criticise it.  My personal opinion is that given large
> >> > state and not so simple update Mersenne Twister would
> >> > have to be very very good to justify its use.    
> >> 
> >> One theoretical advantage of MT19937 is that it has period of
> >> astronomic proportions. Which means that one instance of PRNG
> >> could be de-multiplexed into millions or billions of sub-streams
> >> with no detectable degradation of the quality of each sub-stream.
> >> However I fail to see how de-multiplexing into more than ~ one
> >> thousand of sub-streams can be practical. And for the latter one
> >> does not need to be astronomical, something like period=2**96
> >> would be fully sufficient with many bits to spare.
> >> So, in theory I agree with the criticism. But in practice I am not
> >> bothered by the size of MT state.
> >>   
> >> > But it
> >> > fails some tests, so does not look _better_ than other
> >> > generators.
> >> >    
> >> 
> >> It would be interesting to find out what were those tests that
> >> failed. I wonder, if tests suit can run faster on multicore
> >> computer. I don't want to wait 5-6 hours just to find out that
> >> report does not provide an information that I am looking for.
> >>   
> > 
> > I reproduced results of M. O'Neil. Luckily, on semi-modern hardware
> > (Coffee Lake or EPYC3) and for PRNGs in question BigCrash finishes
> > in 2-2.5 hours. Which is a pain, but considarably less so then 5
> > hours. mt19937 fails all tests of scomp_LinearComp() variaty (2 in
> > Crash and 2 in BigCrash). It passes all the rest of tests.
> > After re-reading O'Neil, I see that she wrote that, but first time I
> > didn't pay attention.
> > 
> > I have read description of scomp_LinearComp(). I can't say that I
> > understood much. Neither theory, nor parameters, in particular, even
> > after looking though code I have no idea about the meaning of
> > parameter r. 
> > I am not so sure that Pierre L’Ecuyer himself fully understands this
> > test, apart from the fact that many moons ago basic algorithm for
> > calculation of linear complexity was published in IEEE Transactions
> > on Information Theory. Otherwise, his description would not look so
> > much as hand waving. As to O'Neil, she likely understands it better
> > than myself, but that's not a huge achievement :(
> > My less than scientific feeling about this test is that one part of
> > it is looking if test is LFSR or LFSR-family and if the answer is
> > yes then test fails.
> > So, eccentrically, mt19937 is punished for what it is rather than
> > for randomness of results that it produces.  
> 
> Well, I peeked at the code but did not read destription of the
> test.  In the code I see mention of Berlekamp-Massey.  That is
> well-known algorithm to find regularites in data, basically
> tries to find linear recurence satisfied by the data.  One of
> things that I do is looking for reccurences, including linear
> ones.  Up to now I did not run any serious simulation for
> such things but I may wish to do so (and IIUC other people did
> run some simulations).  When doing simulations I really do
> not want to see artifacts due to PRNG producing sequence with
> different features than random sequence.  So for me, if mt19937
> produces sequence with visible extra linear regulatities that is
> significant failure.
>

I can't say much about Berlekamp-Massey algorithm in general. But this
particular test (scomp_LinearComp) is looking for correlations between
individual bits and is doing it at unusual intervals. In fact, it's
even worth. It is looking not for correlations themselves but for
regularity in changes of measure of correlation in a group of bits that
is called linear complexity. And if it finds changes regular than it
declares that PRNG is bad.
I don't know, may be the test was not intentionally designed to punish
long LSFRs that use relatively few bits at feedback step, but it
behaves like the one.
I personally don't care even if my PRNG has long-distance correlation
between bits themselves, as long as the distance is long and not
divisible by small integers. Much less so, when its not correlation
itself, but a derivative of some abstract function of correlation.

What I care about are numeric values of groups of bits taken at regular
intervals, like 64 bits (most typical), 32 bits or rarely 8/16 bits.
And for that MT appears to perform very well. For that I certainly
trust it better than non-hashed output of LCG, esp. of LCG that has
pow2 for modulo. And if said LCG happens to pass all L’Ecuyer butteries
it rather makes me more suspect of quality of batteries rather than less
suspect of quality of this sort of LCG.

Now, if somebody cares about non-correlativity of individual bits at
strange intervals then, may be, LCG(mod 2**96) with output consisting
of 32 MS bits of the state is what a doctor ordered. However I suspect
that my usage of PRNG is not just different from his, it also happens to
be far more common than his usage.

> > I made a minimal modification to mt19937 algorithm, telling it to
> > skip every 19936th result word. With modification it easily passes
> > all 3 crash batteries of Pierre L’Ecuyer.
> > Do I think that my modified mt19937 is better than original? No, I
> > don't. IMHO, the only thing it is better in is passing batteries of
> > L’Ecuyer.  
> 
> Your modification is enough to fool the tests.  It is not clear
> to me if it is enough to fool better regularity finders, so
> probably the generator is still defective.
> 

That was my point. I manged to fool the test. Easily. 
But my conclusion is different. The test is defective, generator, both
before and after modifications, is o.k..

> Also, note basic priciple of statistial testing: you should collect
> and process data first, than apply _once_ statitical test.  Repeated
> testing with tweaked data is likely to prodice false pass.  If you
> really want to tweak data the whole thing should be treated as
> one composite test with its own acceptance criteria (which is more
> stringent than separate tests).  Given that you used knowledge of
> failing tests to modify generator, passing test after that is much
> weaker claim than passing test for generator without knowledge of
> the tests.
>

Pay attention that specific skip modulo (19936) was chosen not
because it's the only modulo that cause the test to pass. It was
chosen as a biggest number < 19937 in order to make least noticeable
impact on the speed of PRNG. Any smaller skip modulo will pass tests as
well.
So, if there was feedback loop on my part, it was not strong.

And that, BTW, is my main criticism of methodology of Melissa O'Neil in
constructive part of your article. She seems to apply a feedback loop
by tweaking her suggested PCGs until they pass L’Ecuyer butteries. 

> >> > > On related note, I think that even simple counter fed into high
> >> > > quality hash function (not cryptographically high quality, far
> >> > > less than that) can produce excellent PRNG with even smaller
> >> > > internal state. But not very fast one. Although the speed
> >> > > depends on specifics of used computer. I can imagine computer
> >> > > that has low-latency Rijndael128 instruction. On such
> >> > > computer, running counter through 3-4 rounds of Rijndael ill
> >> > > produce very good PRNG that is only 2-3 times slower than, for
> >> > > example, LCG 128/64.      
> >> > 
> >> > Maybe.
> >> >     
> >> 
> >> May be I'd even test my hypothesis. Eventually. Except that,
> >> again, I am not thrilled by idea of waiting 6 hours for each
> >> result. 
> > 
> > I tested.
> > It turned out that my hypothesis was wrong. Running counter through
> > 3 rounds of Rijndael128 is not enough. Running counter through 4
> > rounds is still not enough - it fails 1 test (#86) in BigCrash
> > battery. I didn't test 5 rounds, but even if it is enough, which is
> > likely, it would almost certainly be slower than other several
> > known methods.
> > 
> > All that with simple 64-bit binary counter as a state variable.
> > 
> > With 128-bit state and with partial chaining of 64 bits of Rijndael
> > output back into part of state (the other half of state is still a
> > counter), passing all batteries appear very easy. It only takes one
> > round for chaining and another one for hashing. But under O'Neil's
> > figures of merit using 128-bit PRNG state considered cheating );  
> 
> O'Neil writes about birtday test: if you take values from N
> element set, with more than sqrt(N) samples you should get
> repetitions.  Consider N equal to 2 to the power 64.  In
> heavy use one could generate more than sqrt(N) values.
> In PRNG having 64-bit state and producing state as value
> all values are distinct, so generator would fail such a test.
> One could try to fix this by not exposing state, say producing
> only 32-bits in each step.

Using 64-bit state and generating 32-bit output at each step is exactly
what I did. In theory it should suffice to pass birthday tests.
And indeed the test that failed was not one of the birthday tests, but
svaria_WeightDistrib test (# 62 in BigCrash).

> But on 64-bit machine it looks
> more efficient to use 128-bit state and produce 64-bits in
> each step.
>

It was not about practicality, but about testing the theory that even
the worst possible long-periodic PRNG (and I can not think about
anything worse as PRNG than simple counter) should be good enough when
fed into decent hash as long as one is not greedy and (assuming
2**64 period) one does not try to use more than 32 bits for output.
I still think that the theory is correct, but I somewhat underestimated
the required quality of the hash function.

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

Thread

srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-22 08:48 +0000
  Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 06:44 -0500
    Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 13:18 +0100
      Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 12:13 -0500
        Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 18:41 +0100
          Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-22 20:45 +0200
            Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-22 21:16 +0000
            Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:19 +0100
            Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:57 +0100
              Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 11:18 +0200
                Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 10:54 +0100
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 13:50 +0200
                Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 18:29 -0500
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 16:30 -0800
            Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-23 17:54 +0000
              Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 00:08 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 02:02 +0000
                Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 23:43 -0500
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 05:34 +0000
                Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-24 09:00 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 12:12 +0200
                Article of Melissa O'Nail (Was: srand(0)) Michael S <already5chosen@yahoo.com> - 2025-12-28 02:44 +0200
                Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2025-12-28 05:38 +0000
                Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2025-12-28 12:35 +0200
                Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-05 14:21 +0200
                Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2026-01-07 10:51 +0000
                Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-08 14:03 +0200
                Re: Article of Melissa O'Nail Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:40 -0800
                Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:26 -0800
                Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 13:48 -0800
                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) BGB <cr88192@gmail.com> - 2025-12-24 05:22 -0600
                Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:09 -0600
                Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:51 +0100
                Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 04:24 -0600
              Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:50 -0800
            Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:46 -0800
              Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-07 18:14 +0200
          Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-22 19:16 +0000
            Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:35 +0100
      Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:24 +0000
        Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 09:59 +0100
          Re: srand(0) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2025-12-23 11:09 +0100
            Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:49 +0000
          Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:13 +0000
            Re: srand(0) richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-12-23 19:05 +0000
        Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 02:16 -0800
          Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:47 +0000
        Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:08 +0000
          Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:44 +0000
    Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:17 +0000
      Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 08:25 +0100
        Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:45 +0000
          Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 19:15 +0100
  Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 00:39 +0000
    Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-23 02:17 +0000
      Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:55 +0000
        Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:35 -0600
          Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:23 +0000
            Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 14:48 -0600
              Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 15:12 -0600
    Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-23 06:49 +0000
      Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 20:37 +0000
        Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-24 15:22 +0000
    Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:25 +0000
      Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 06:16 +0000
        Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:21 +0000
          Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 19:00 +0000
            Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 03:07 -0600
              Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 19:31 +0000
                Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 21:14 +0100
                Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 15:29 -0600
                Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-25 23:25 -0500
                Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 23:41 -0600
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 05:42 +0000
                Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-26 01:52 -0500
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 07:56 +0000
                Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 04:48 -0600
      Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 10:51 +0200
        Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 00:59 -0800
        Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:28 +0000
          Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 17:44 +0200
            Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 16:17 +0000
              Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 17:53 +0100
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:27 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:33 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 20:16 +0200
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 02:01 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 03:17 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:13 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 04:30 +0000
                Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:10 +0100
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:08 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 06:07 +0000
                Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-30 18:42 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 02:01 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 03:10 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 03:28 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 09:37 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:32 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:02 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 19:20 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 21:53 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 23:50 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 14:32 +0200
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 16:18 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:52 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:46 +0000
                Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-03 04:08 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 04:39 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-03 14:24 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-03 20:38 +0200
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:37 -0800
                Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-31 17:24 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:17 -0800
                Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 12:30 -0500
                Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 18:42 +0000
                Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 15:07 -0500
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 22:18 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:55 +0000
                Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 22:57 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:00 -0800
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 01:03 +0000
                Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 14:05 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:03 +0000
                Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 20:28 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:29 -0800
                Re: srand(0) highcrew <high.crew3868@fastmail.com> - 2026-01-01 00:31 +0100
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:05 -0800
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:29 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:52 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:14 -0800
                Re: srand(0) Geoff <geoff@invalid.invalid> - 2026-01-05 20:00 -0800
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:03 -0800
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:35 -0800
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 04:51 +0000
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:15 +0200
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:51 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:00 -0800
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 01:45 +0200
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:34 -0800
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:23 +0000
                Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-01 02:01 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 02:29 +0000
                Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-30 06:34 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 14:05 +0000
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-28 05:51 +0000
            Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-24 17:08 +0000
    Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:39 -0800
      Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:54 -0800
        Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 15:34 +0000
          Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 14:44 -0800
            Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 06:06 +0000
              Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 22:46 -0800
                Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 22:38 +0000
                Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2026-01-09 23:27 +0000
                Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-09 17:09 -0800
                Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-10 19:44 +0000
        Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 00:36 -0800
  Re: srand(0) Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-23 11:04 +0100
  Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-23 21:44 -0800
    Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:41 +0000
      Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 18:04 +0100
        Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 05:41 +0000
  Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 02:57 +0000

csiph-web