Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.math.num-analysis > #34106

Re: srand(0)

Cross-posted to 2 groups.

Show key headers only | View raw

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
> >   
> 

Back to sci.math.num-analysis | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: srand(0) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-18 11:21 +0000
  Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 10:01 +0100
    Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-19 14:33 -0500
      Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 20:47 +0100
        Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-20 16:01 -0500
          Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-21 11:09 +0100
    Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-19 14:39 -0800
      Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-20 09:16 +0100
        Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 08:32 -0500
          Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 16:05 +0100
            Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-23 19:59 +0200
              Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 20:06 +0100
                Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 15:24 -0500
                Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-24 07:08 +0100
                Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-24 10:24 +0100
                Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-26 19:13 +0100
                Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-24 18:36 +0200
                Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-24 20:00 +0100
                Re: srand(0) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-24 18:00 +0000

csiph-web