Groups | Search | Server Info | Login | Register
Groups > sci.math.num-analysis > #34107
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c, sci.math.num-analysis |
| Subject | Re: srand(0) |
| Date | 2026-02-23 20:06 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <10ni8ff$38dk0$1@dont-email.me> (permalink) |
| References | (15 earlier) <87ikbsgxy2.fsf@example.invalid> <10n9584$7int$1@dont-email.me> <10nhktn$31293$1@dont-email.me> <10nhqc9$32dop$1@dont-email.me> <20260223195917.000028af@yahoo.com> |
Cross-posted to 2 groups.
On 23/02/2026 18:59, Michael S wrote: > 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. > 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-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
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