What this comes down to is that you just can't arbitrarily choose a random number and hope that it meets your needs.
You have to understand what properties you actually care about and choose a (P)RNG that has those properties.
You have to understand what properties you actually care about and choose a (P)RNG that has those properties.
Perhaps this is because true randomness doesn't always appear to be random enough. I would argue that this property is what makes it real. Sometimes true randomness might be six dice all showing the face of six.
For many use cases in statistics / sampling / monte carlo simulations, you often need millions/billions of well-distributed random numbers with very low generation overhead.
Even things like game AIs care about performance with regards to the RNGs they use.
(A few notes on the second link: I wouldn’t recommend xoshiro256+x8 since it is very weak statistically, same for xoshiro256 IMO. Also, disclaimer, I wrote SHISHUA.)
I suppose that this is probably indicative of a more fundamental weakness, but for reference the upper bits should be way higher quality that the Messene Twister (As that one fails PractRand while the upper bits of xoshiro256+ don't IIRC)
That said, there are certainly use-cases for it! I just like the idea that we can have our cake and eat it too: something closer to the Pareto frontier, that doesn’t have those caveats, and yet is faster.
I don't dispute that at the bit level using something like PractRand it has issues and there are better "quality" ones, but at a practical sense in generating excellent 0.0f -> 1.0f float32 numbers and uint32_t indices I couldn't actually notice any quality issues with what it generated for very long running Monto Carlo simulations using billions of random numbers, even though it should have been causing issues with the integer numbers due to the weaker lower bits (although in practice, most of the indices were < 16 bits in size, so that might have explained it).
I wasn't aware of SHISHUA though, I'll check it out.