My goto RNG for a small, supposedly cryptographical secure RNG is ISAAC. https://en.wikipedia.org/wiki/ISAAC_(cipher) (There's a standalone C code implementation available at https://ccodearchive.net/info/isaac.html)
It is high time we let go of the Mersenne Twister (2019)
21–30 of 56 posts
Re: It is high time we let go of the Mersenne Twister (2019)
#22Is there anything wrong with ARC4 as a fast non cryptographic generator?
Re: It is high time we let go of the Mersenne Twister (2019)
#23As just a datapoint from some random person, I needed a pseudo-random number generator just last week. My use-case is semi-embedded, with two applications running on different hardware and operating systems, that both needed to generate streams of the same random data. I first naively went with just rand() to get it running, but obviously there's no guerantee that two completely different platforms' C libraries have…
Xorshift is one of my favorites.
I always worry about default random numbers in the standard library, because there might still be that awful and badly performing(On embedded without multiply) LCG hiding.
Re: It is high time we let go of the Mersenne Twister (2019)
#24Is there anything wrong with ARC4 as a fast non cryptographic generator?
RC4 works fine. The only "problem" is its large state (2048) compared to the common LCG and Xorshift PRNGs which typically have anywhere between 32 and 256 bits of state.
Sqlite3 uses RC4 for its random functions.
Re: It is high time we let go of the Mersenne Twister (2019)
#25The author of this paper suggests their xoshiro256 from the Xoshiro family[1] as an alternative. I found some discussion here[2] where it's suggested it has some fatal flaws as well, though I'm no expert. Back when I wrote a path tracer, the quality of the random number generator was visible. The poor LCG[3] that my programming language sported resulted in obvious patterns in what should have been random noise. So, f…
For Monte Carlo integration you want low discrepancy sequences or blue noise, not random numbers.
That's easier said then done, when you integrate over a high dimensional (possibly infinite) space.
Re: It is high time we let go of the Mersenne Twister (2019)
#26As just a datapoint from some random person, I needed a pseudo-random number generator just last week. My use-case is semi-embedded, with two applications running on different hardware and operating systems, that both needed to generate streams of the same random data. I first naively went with just rand() to get it running, but obviously there's no guerantee that two completely different platforms' C libraries have…
I came to a similar conclusion when I was looking for a simple RNG. I chose the top 32 bits of xorshift64* [1], as it was noted that it passes BigCrush. Of course, that probably comes at a performance cost. [1]: https://github.com/cgmb/euler/blob/a906355343dc0d320858a7b00...
It's unlikely xorshift64 top bits pass bigcrush.
RNG_test using PractRand version 0.95
RNG = RNG_stdin32, seed = unknown
test set = core, folding = standard (32 bit)
rng=RNG_stdin32, seed=unknown
length= 512 megabytes (2^29 bytes), time= 3.1 seconds
Test Name Raw Processed Evaluation
BRank(12):128(4) R= +2544 p~= 4e-1354 FAIL !!!!!!!!
BRank(12):256(4) R= +8055 p~= 4e-4285 FAIL !!!!!!!!
BRank(12):384(1) R= +6783 p~= 5e-2043 FAIL !!!!!!!!
BRank(12):512(2) R=+13490 p~= 8e-4062 FAIL !!!!!!!!
BRank(12):768(1) R=+15050 p~= 2e-4531 FAIL !!!!!!!!
BRank(12):1K(2) R=+29077 p~= 4e-8754 FAIL !!!!!!!!
BRank(12):1536(1) R=+31582 p~= 2e-9508 FAIL !!!!!!!!
BRank(12):2K(1) R=+42604 p~= 0 FAIL !!!!!!!!
[Low8/32]BRank(12):128(4) R= +2544 p~= 4e-1354 FAIL !!!!!!!!
[Low8/32]BRank(12):256(4) R= +8055 p~= 4e-4285 FAIL !!!!!!!!
[Low8/32]BRank(12):384(1) R= +6783 p~= 5e-2043 FAIL !!!!!!!!
[Low8/32]BRank(12):512(2) R=+13490 p~= 8e-4062 FAIL !!!!!!!!
[Low8/32]BRank(12):768(1) R=+15050 p~= 2e-4531 FAIL !!!!!!!!
[Low8/32]BRank(12):1K(2) R=+29077 p~= 4e-8754 FAIL !!!!!!!!
[Low8/32]BRank(12):1536(1) R=+31582 p~= 2e-9508 FAIL !!!!!!!!
[Low1/32]BRank(12):128(4) R= +2544 p~= 4e-1354 FAIL !!!!!!!!
[Low1/32]BRank(12):256(2) R= +5696 p~= 1e-1715 FAIL !!!!!!!!
[Low1/32]BRank(12):384(1) R= +6783 p~= 5e-2043 FAIL !!!!!!!!
[Low1/32]BRank(12):512(2) R=+13490 p~= 8e-4062 FAIL !!!!!!!!
[Low1/32]BRank(12):768(1) R=+15050 p~= 2e-4531 FAIL !!!!!!!!
...and 160 test result(s) without anomalies
uint64_t lemire64(void) {
static uint128_t s =
(uint128_t)426679527491843471 > 64;
}Re: It is high time we let go of the Mersenne Twister (2019)
#27Earlier quoted context omitted.
I would take that with a pinch of salt. The PCG and Xoshiro guys seem to have some kind of feud so some of the criticisms might not be as big a problem as they are made out to be in practice. Here's a partial rebuttal: https://www.reddit.com/r/programming/comments/8gx2d3/new_lin... For a bit of "social proof" xoshiro256++ is the default PRNG is Julia.
Sebastiano Vigna seems to have a beef. For all I've seen M.E. O'Neill has handled the situation really well. Taking Vignas claims and critique seriously. https://www.pcg-random.org/posts/on-vignas-pcg-critique.html
Here's Vigna's random function if anyone's curious.
uint64_t vigna_r(uint64_t state[static 1]) {
uint64_t z = (state[0] += 0x9e3779b97f4a7c15);
z = (z ^ (z >> 30)) * 0xbf58476d1ce4e5b9;
z = (z ^ (z >> 27)) * 0x94d049bb133111eb;
return z ^ (z >> 31);
}
Re: It is high time we let go of the Mersenne Twister (2019)
#28The author of this paper suggests their xoshiro256 from the Xoshiro family[1] as an alternative. I found some discussion here[2] where it's suggested it has some fatal flaws as well, though I'm no expert. Back when I wrote a path tracer, the quality of the random number generator was visible. The poor LCG[3] that my programming language sported resulted in obvious patterns in what should have been random noise. So, f…
> The author of this paper suggests their xoshiro256 from the Xoshiro family[1] as an alternative. I found some discussion here[2] where it's suggested it has some fatal flaws as well, though I'm no expert. PRNGs are complicated, and sometimes we don’t find out flaws in them until long after they are widely deployed – although test suites like U01 Big Crush and PractRand should really help that situation out. Part of…
To be fair, you should expect to learn state of the art CS in a Computational Physics class. That’s not the goal..
Re: It is high time we let go of the Mersenne Twister (2019)
#29Earlier quoted context omitted.
> The author of this paper suggests their xoshiro256 from the Xoshiro family[1] as an alternative. I found some discussion here[2] where it's suggested it has some fatal flaws as well, though I'm no expert. PRNGs are complicated, and sometimes we don’t find out flaws in them until long after they are widely deployed – although test suites like U01 Big Crush and PractRand should really help that situation out. Part of…
Also, one should compare the properties with the Mersenne Twister. The new PRNG proposals, algporitjms have better properties than the Mersenne Twister. Which one is best is a moving target. The point is that there are better to the Mersenne Twister alternatives today. It is a bit like people still choose to use MD5 or SHA-1. They are choosen because they are well known, easy to find info about and implementations to…
mt19937 is on the PractRand recommended list. https://github.com/MartyMacGyver/PractRand/blob/6ae26d8d4023... But it's last and his top recommendation is based on hc256 https://github.com/peterferrie/hc256
Re: It is high time we let go of the Mersenne Twister (2019)
#30As just a datapoint from some random person, I needed a pseudo-random number generator just last week. My use-case is semi-embedded, with two applications running on different hardware and operating systems, that both needed to generate streams of the same random data. I first naively went with just rand() to get it running, but obviously there's no guerantee that two completely different platforms' C libraries have…