XPost: sci.math.num-analysis   
   From: david.brown@hesbynett.no   
      
   On 23/02/2026 18:59, Michael S wrote:   
   > 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.   
   >   
      
   Weirdly (at least /I/ think it is weird), it is easier to calculate   
   hexadecimal digits of pi than decimal digits.  At least, it is possible   
   to calculate them independently, without having to calculate and   
   remember all the previous digits.  So it should be possible to split the   
   task up and run it in parallel on multiple systems.   
      
   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.   
      
   >>   
   >>> 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-   
   ovember/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)