But your original statement implied that clang would *use* that
particular piece of code, which didn't make much sense. Were you
just asking about how the __OpenBSD__ macro is defined, without
reference to srand?
On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote:
But your original statement implied that clang would *use* that
particular piece of code, which didn't make much sense. Were you
just asking about how the __OpenBSD__ macro is defined, without
reference to srand?
Well, under OpenBSD I plan on using:
#ifdef __OpenBSD__
srand_deterministic(seed);
#else
srand(seed);
#endif
But what I was asking is whether or not gcc would recognize
the __OpenBSD__ macro (why wouldn't I'm assuming) since clang
is the default compiler.
But also about srand()... you've got me really wondering why
OpenBSD would deviate from the standard as they have. I get
that the those folks disagree because its deterministic, but
its the accepted standard to be deterministic with srand().
Only speaking for myself here, rather than srand_deterministic()
and srand() (that's not deterministic under OpenBSD) it
would've made more sense to've implemented srand_non_deterministic()
and left srand() alone. That design decision on their part only
muddies the waters in my thinking. Live & learn =)
On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote:
But your original statement implied that clang would *use* that
particular piece of code, which didn't make much sense. Were you
just asking about how the __OpenBSD__ macro is defined, without
reference to srand?
Well, under OpenBSD I plan on using:
#ifdef __OpenBSD__
srand_deterministic(seed);
#else
srand(seed);
#endif
But what I was asking is whether or not gcc would recognize
the __OpenBSD__ macro (why wouldn't I'm assuming) since clang
is the default compiler.
But also about srand()... you've got me really wondering why
OpenBSD would deviate from the standard as they have. I get
that the those folks disagree because its deterministic, but
its the accepted standard to be deterministic with srand().
Only speaking for myself here, rather than srand_deterministic()
and srand() (that's not deterministic under OpenBSD) it
would've made more sense to've implemented srand_non_deterministic()
and left srand() alone. That design decision on their part only
muddies the waters in my thinking. Live & learn =)
On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote:
But your original statement implied that clang would *use* that
particular piece of code, which didn't make much sense. Were you
just asking about how the __OpenBSD__ macro is defined, without
reference to srand?
Well, under OpenBSD I plan on using:
#ifdef __OpenBSD__
srand_deterministic(seed);
#else
srand(seed);
#endif
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]
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.
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?
On Tue, 03 Feb 2026 05:26:47 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
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.
I don't think that it is possible to create generic empirical tests
of this sort.
What is possible is a test that measures specific property that is
known to be important for specific use.
If you don't think there is any such test, how do you propose that
PRNGs be evaluated?
I don't know.
But I believe in one philosophical principle that I learned first ~40
years ago in the field unrelated to PRNGs or to Computer Science:
when you don't know how to measure quality of your product then it is advisable to ask your consumer. Do not ask a random consumer, ask the
one who requested improvement of the property that you have
difficulties to measure. He is the most likely one to know.
The field where I first heard about that principle was manufacturing
of ultra-pure chemicals.
The key property of a (pseudo) random number generator is that the
values produced exhibit no discernible pattern.
On 18/02/2026 07:47, Tim Rentsch wrote:
The key property of a (pseudo) random number generator is that the
values produced exhibit no discernible pattern.
For a PRNG, they exhibit the pattern of following the sequence of the PRNG!
Is it that, for any finite sequence of numbers from a PRNG, without information about where it came from and how many numbers came before
you can't predict the next number better than chance?
On 18/02/2026 12:21, Tristan Wibberley wrote:
On 18/02/2026 07:47, Tim Rentsch wrote:
The key property of a (pseudo) random number generator is that the
values produced exhibit no discernible pattern.
For a PRNG, they exhibit the pattern of following the sequence of the PRNG! >>
As a deterministic function, a PRNG will obviously follow the pattern of
its generating function. But the aim is to have no /discernible/
pattern. The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and thus
no way to predict the next number, 9, in the sequence. But there is a pattern there - it's the 90th - 100th digits of the decimal expansion of pi.
On 2026-02-19 04:01, David Brown wrote:
On 18/02/2026 12:21, Tristan Wibberley wrote:
On 18/02/2026 07:47, Tim Rentsch wrote:
The key property of a (pseudo) random number generator is that the
values produced exhibit no discernible pattern.
For a PRNG, they exhibit the pattern of following the sequence of the PRNG! >>>
As a deterministic function, a PRNG will obviously follow the pattern of
its generating function. But the aim is to have no /discernible/
pattern. The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and thus
no way to predict the next number, 9, in the sequence. But there is a
pattern there - it's the 90th - 100th digits of the decimal expansion of pi.
I think you're being overoptimistic. I suspect that the pattern could be identified, exactly, without knowing how it was generated. That's
because every possible pattern has infinitely many different ways in
which in can be produced. One of those other ways might be easier to
describe than the way in which the numbers were actually produced, in
which case that simpler way might be guessed more easily that the actual
one - possibly a lot easier.
As a deterministic function, a PRNG will obviously follow the pattern[...]
of its generating function. But the aim is to have no /discernible/
pattern. The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and
thus no way to predict the next number, 9, in the sequence. But there
is a pattern there - it's the 90th - 100th digits of the decimal
expansion of pi.
David Brown <david.brown@hesbynett.no> writes:
[...]
As a deterministic function, a PRNG will obviously follow the pattern[...]
of its generating function. But the aim is to have no /discernible/
pattern. The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and
thus no way to predict the next number, 9, in the sequence. But there
is a pattern there - it's the 90th - 100th digits of the decimal
expansion of pi.
A Google search for 342117067 gives numerous hits referring to the
digits of pi.
How likely is it that someone would guess a formula that happened to
generate the decimal digits of pi, without more knowledge than a part
of the sequence? I don't believe it is possible to quantify such a probability, but I would expect it to be very low.
On 2026-02-19 14:47, David Brown wrote:
...
How likely is it that someone would guess a formula that happened to
generate the decimal digits of pi, without more knowledge than a part
of the sequence? I don't believe it is possible to quantify such a
probability, but I would expect it to be very low.
I'm thinking of the kind of software that looks for patterns in
something, such as compression utilities. A compression utility
basically converts a long string of numbers into a much shorter string
that can be expanded by the decompression utility to recover the
original pattern. If you look at the algorithms such code uses, you
realize that they do not attempt to recreate the process that originally generated the long string, they just, in effect, characterize the
resulting sequence.
On 19/02/2026 23:39, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
As a deterministic function, a PRNG will obviously follow the pattern[...]
of its generating function.˙ But the aim is to have no /discernible/
pattern.˙ The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and
thus no way to predict the next number, 9, in the sequence.˙ But there
is a pattern there - it's the 90th - 100th digits of the decimal
expansion of pi.
A Google search for 342117067 gives numerous hits referring to the
digits of pi.
That is using knowledge of where the sequence comes from - something else's knowledge rather than your own, but it's the same principle.
On Fri, 2/20/2026 3:16 AM, David Brown wrote:
On 19/02/2026 23:39, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
As a deterministic function, a PRNG will obviously follow the pattern[...]
of its generating function.˙ But the aim is to have no /discernible/
pattern.˙ The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7 has no pattern that
could be identified without knowledge of where they came from - and
thus no way to predict the next number, 9, in the sequence.˙ But there >>>> is a pattern there - it's the 90th - 100th digits of the decimal
expansion of pi.
A Google search for 342117067 gives numerous hits referring to the
digits of pi.
That is using knowledge of where the sequence comes from - something else's knowledge rather than your own, but it's the same principle.
"In the following sequence, what is the next digit 7,7,7,7,7,7,7,7,7 ? " :-)
PI=3.
1415926535 8979323846 2643383279 5028841971 6939937510
...
7777777772 4846769425 9310468643 5260899021 0266057232 # Line 517834
I suspect seeing that, that's not good.
Using pgmp-chudnovsky.c , and dumping pi as a binary float to a file,
I get this:
(text version of PI) 100,000,022 bytes
PI-Binary.bin 41,524,121 bytes exponent and limbs
PI-Binary.bin.7Z 41,526,823 bytes 7Z Ultra compression, running on 1 core
The entropy property looks pretty good, but I doubt I would
be using that for my supply of random numbers :-)
https://gmplib.org/list-archives/gmp-discuss/2008-November/003444.html https://stackoverflow.com/questions/3318979/how-to-serialize-the-gmp-mpf-type
https://gmplib.org/list-archives/gmp-discuss/2007-November/002981.html
gcc -DNO_FACTOR -fopenmp -Wall -O2 -o pgmp-chudnovsky pgmp-chudnovsky.c -lgmp -lm
Paul
On 23/02/2026 14:32, Paul wrote:
On Fri, 2/20/2026 3:16 AM, David Brown wrote:
On 19/02/2026 23:39, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
As a deterministic function, a PRNG will obviously follow the[...]
pattern of its generating function.˙ But the aim is to have no
/discernible/ pattern.˙ The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7
has no pattern that could be identified without knowledge of
where they came from - and thus no way to predict the next
number, 9, in the sequence.˙ But there is a pattern there - it's
the 90th - 100th digits of the decimal expansion of pi.
A Google search for 342117067 gives numerous hits referring to the
digits of pi.
That is using knowledge of where the sequence comes from -
something else's knowledge rather than your own, but it's the same
principle.
"In the following sequence, what is the next digit
7,7,7,7,7,7,7,7,7 ? " :-)
PI=3.
1415926535 8979323846 2643383279 5028841971 6939937510
...
7777777772 4846769425 9310468643 5260899021 0266057232 # Line
517834
I suspect seeing that, that's not good.
Using pgmp-chudnovsky.c , and dumping pi as a binary float to a
file, I get this:
(text version of PI) 100,000,022 bytes
PI-Binary.bin 41,524,121 bytes exponent and limbs
PI-Binary.bin.7Z 41,526,823 bytes 7Z Ultra
compression, running on 1 core
The entropy property looks pretty good, but I doubt I would
be using that for my supply of random numbers :-)
In a random sequence of decimal digits, you would expect a sequence
of nine identical digits to turn up on average every 10 ^ 8 digits or
so. You calculated 10 ^ 8 digits, so it's not surprising to see that
here.
As for your compression, remember that your text file contains only
the digits 0 to 9, spaces and newlines - 12 different characters in
8-bit bytes. If these were purely randomly distributed, you'd expect
a best compression ratio of log(12) / log(256), or 0.448. But they
are not completely random - your space characters and newlines are predictably spaced so you get marginally better compression ratios.
Without spaces and newlines, you'd expect log(10) / log(256)
compression - 0.415241012. What a coincidence - this matches your
"exponent and limbs", and your compressor can't improve on it. (I
downloaded a billion digits of pi and gzip'ed it, for a compression
ration of 0.469.)
It turns out that the pseudo-randomness here is extremely good.
While it has not been proven that pi is "normal" (that is to say, its
digits are all evenly distributed), it is strongly believed to be so.
Of course it's not a great source of entropy for secure random
numbers, but the digits of pi form a fine pseudo-random generator
function (if you don't mind the calculation time).
f-typehttps://gmplib.org/list-archives/gmp-discuss/2008-November/003444.html https://stackoverflow.com/questions/3318979/how-to-serialize-the-gmp-mp
981.htmlhttps://gmplib.org/list-archives/gmp-discuss/2007-November/002
gcc -DNO_FACTOR -fopenmp -Wall -O2 -o pgmp-chudnovsky
pgmp-chudnovsky.c -lgmp -lm
Paul
On Mon, 23 Feb 2026 16:05:45 +0100
David Brown <david.brown@hesbynett.no> wrote:
On 23/02/2026 14:32, Paul wrote:
On Fri, 2/20/2026 3:16 AM, David Brown wrote:
On 19/02/2026 23:39, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
As a deterministic function, a PRNG will obviously follow the[...]
pattern of its generating function.˙ But the aim is to have no
/discernible/ pattern.˙ The sequence 3, 4, 2, 1, 1, 7, 0, 6, 7
has no pattern that could be identified without knowledge of
where they came from - and thus no way to predict the next
number, 9, in the sequence.˙ But there is a pattern there - it's
the 90th - 100th digits of the decimal expansion of pi.
A Google search for 342117067 gives numerous hits referring to the
digits of pi.
That is using knowledge of where the sequence comes from -
something else's knowledge rather than your own, but it's the same
principle.
"In the following sequence, what is the next digit
7,7,7,7,7,7,7,7,7 ? " :-)
PI=3.
1415926535 8979323846 2643383279 5028841971 6939937510
...
7777777772 4846769425 9310468643 5260899021 0266057232 # Line
517834
I suspect seeing that, that's not good.
Using pgmp-chudnovsky.c , and dumping pi as a binary float to a
file, I get this:
(text version of PI) 100,000,022 bytes
PI-Binary.bin 41,524,121 bytes exponent and limbs
PI-Binary.bin.7Z 41,526,823 bytes 7Z Ultra
compression, running on 1 core
The entropy property looks pretty good, but I doubt I would
be using that for my supply of random numbers :-)
In a random sequence of decimal digits, you would expect a sequence
of nine identical digits to turn up on average every 10 ^ 8 digits or
so. You calculated 10 ^ 8 digits, so it's not surprising to see that
here.
As for your compression, remember that your text file contains only
the digits 0 to 9, spaces and newlines - 12 different characters in
8-bit bytes. If these were purely randomly distributed, you'd expect
a best compression ratio of log(12) / log(256), or 0.448. But they
are not completely random - your space characters and newlines are
predictably spaced so you get marginally better compression ratios.
Without spaces and newlines, you'd expect log(10) / log(256)
compression - 0.415241012. What a coincidence - this matches your
"exponent and limbs", and your compressor can't improve on it. (I
downloaded a billion digits of pi and gzip'ed it, for a compression
ration of 0.469.)
It turns out that the pseudo-randomness here is extremely good.
While it has not been proven that pi is "normal" (that is to say, its
digits are all evenly distributed), it is strongly believed to be so.
Of course it's not a great source of entropy for secure random
numbers, but the digits of pi form a fine pseudo-random generator
function (if you don't mind the calculation time).
Would be interesting to find out if it passes Big Crash of L?Ecuyer.
Of course, one would need far more than a billion of decimal digits to
have a chance. Something like 100B hexadecimal digits appears to be a minimum.
https://gmplib.org/list-archives/gmp-discuss/2008-November/003444.html
https://stackoverflow.com/questions/3318979/how-to-serialize-the-gmp-mpf-type
https://gmplib.org/list-archives/gmp-discuss/2007-November/002981.html
gcc -DNO_FACTOR -fopenmp -Wall -O2 -o pgmp-chudnovsky
pgmp-chudnovsky.c -lgmp -lm
Paul
˙˙˙˙˙ (text version of PI)˙ 100,000,022 bytes
˙˙˙˙˙ PI-Binary.bin˙˙˙˙˙˙˙˙˙ 41,524,121 bytes˙˙ exponent and limbs
Weirdly (at least /I/ think it is weird), it is easier to calculate hexadecimal digits of pi than decimal digits.
Of course, confirming that the hexadecimal digits of pi are random
enough to pass such a test does not ensure that the decimal digits
would do so too.
David Brown <david.brown@hesbynett.no> writes:
Of course, confirming that the hexadecimal digits of pi are random
enough to pass such a test does not ensure that the decimal digits
would do so too.
I was puzzled by the "Of course": To me, this is not intuitively clear.
Is there any easy (not too technical) way to "see this"/make it
plausible? My gut feeling (wrongly?) said that the base should not
affect the randomness of a numerical pattern. "Of course" I am aware
(and taught to dozens of numerical beginners) that, say, 0.5 in base 10
has a non terminating representation in base 2, but "random" is neither representation.
Pointers or simple counter-examples highly welcome!
Axel
Numbers can be normal in some bases and not in others. This is easy to
see if we pick related bases, such as base 2 and base 16. For example,
let x be 1/3. Then x is 0.0101010101... in base 2. That is clearly
normal in base 2. But in base 16, it is 0.55555555..., which is
clearly very far from normal.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 84:48:08 |
| Calls: | 208 |
| Files: | 21,502 |
| Messages: | 81,378 |