XPost: sci.math.num-analysis
From: already5chosen@yahoo.com
On Mon, 23 Feb 2026 16:05:45 +0100
David Brown 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 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-N
vember/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)
|
