Groups | Search | Server Info | Login | Register
Groups > comp.lang.c > #396693
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Newsgroups | comp.lang.c, sci.math.num-analysis |
| Subject | Re: srand(0) |
| Date | 2026-02-23 19:59 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <20260223195917.000028af@yahoo.com> (permalink) |
| References | (14 earlier) <10n6jgg$3bj7e$1@dont-email.me> <87ikbsgxy2.fsf@example.invalid> <10n9584$7int$1@dont-email.me> <10nhktn$31293$1@dont-email.me> <10nhqc9$32dop$1@dont-email.me> |
Cross-posted to 2 groups.
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 comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 08:41 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-08 01:06 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:26 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-03 16:37 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:47 -0800
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
csiph-web