On Mon, 9 Jan 2023 at 23:38, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I tried this on some 32-bit big-endian hardware (NetBSD on macppc) > to verify my thesis that the results of random() are now machine > independent. That part works, but the random_normal() tests didn't;
Ah yes, I wondered about that. > I saw low-order-bit differences from the results on x86_64 Linux. > Presumably, that's because one or more of sqrt()/log()/sin() are > rounding off a bit differently there. v2 attached deals with this by > backing off to "extra_float_digits = 0" for that test. Makes sense. I double-checked the one-in-a-billion claim, and it looks about right for each test. The one I wasn't sure about was the chance of duplicates for random_normal(). Analysing it more closely, it actually has a smaller chance of duplicates, since the difference between 2 standard normal distributions is another normal distribution with a standard deviation of sqrt(2), and so the probability of a pair of random_normal()'s being the same is about 2*sqrt(pi) ~ 3.5449 times lower than for random(). So you can call random_normal() around 5600 times (rather than 3000 times) before having a 1e-9 chance of duplicates. So, as with the random() duplicates test, the probability of failure with just 1000 values should be well below 1e-9. Intuitively, that was always going to be true, but I wanted to know the details. The rest looks good to me, except there's a random non-ASCII character instead of a hyphen in "Kolmogorov-Smirnov" (because I copy-pasted the name from some random website). Regards, Dean
