Re: rand48 replacement

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
>> Good, but then you shouldn't write associated code as if that's still
>> a problem, because you'll cause other people to think it's still a
>> problem and write equally contorted code elsewhere. "v & 1" is a
>> transparent way of producing a bool, while this code isn't.

> Some Xoshiro-family generators have "linear artifacts in the low bits",
> Although Xoroshiro128** is supposed to be immune, I thought better to keep
> away from these, and I could not see why the last bit would be better than
> any other bit, so taking the first looked okay to me at least.

Meh. If we're going to trust the high bits more than the lower ones,
we should do so consistently; it makes no sense to do that in one
pg_prng.c function and not its siblings.

Pushed with that change and some others, notably:

* Rewrote a lot of the comments.
* Refactored so that pg_strong_random() is not called from pg_prng.c.
As it stood, that would result in pulling in OpenSSL in programs that
have no need of it. (ldexp() still creates a dependency on libm, but
I figured that was OK.)
* Changed a number of call sites that were using modulo reduction
to use pg_prng_uint64_range instead. Given the lengthy discussion
we had, it seems silly not to apply the conclusion everywhere.

regards, tom lane