XPost: sci.math.num-analysis
From: david.brown@hesbynett.no
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 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).
> 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-Nov
mber/002981.html
>
> gcc -DNO_FACTOR -fopenmp -Wall -O2 -o pgmp-chudnovsky pgmp-chudnovsky.c
-lgmp -lm
>
> Paul
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
