Re-work PR 24105 to support threads and otherwise clean up

[tonycoz]

This is a expansion of #24105 which:

• adds threading support
• also updates the "internal" RNG to use the same RNG
• split out the random number generator code into separate headers/implementation files
• produce an NV instead of a double, since they have the bits of randomness to support larger floats
• config cleanup

I've pointed the author of #24105 at this branch in the past.

---

• This set of changes requires a perldelta entry, and I need help writing it.

[scottchiefbaker]

produce an NV instead of a double, since have have the bits of randomness to support larger floats

I'm trying to figure out what this could mean. Can you clarify the double "have" in this sentence?

Also is this PR merge-able? What else needs to be done?

[tonycoz]

produce an NV instead of a double, since have have the bits of randomness to support larger floats

I'm trying to figure out what this could mean. Can you clarify the double "have" in this sentence?

My typo, should be: "since they have the bits ..."

In particular, you can build perl with it's internal floating point as long double (-Duselongdouble) or __float128 (-Dusequadmath) which have more bits of precision than a double.

Also is this PR merge-able? What else needs to be done?

Probably in 5.45.0, but I'd like some review.

[Leont]

Probably in 5.45.0, but I'd like some review.

Yeah I'd lean towards that too, we're quite late in the cycle for 5.44 now.

[scottchiefbaker]

I agree 100% this should target Perl v5.45, because we're too late into the release cycle. I will poke around with this code, see if I can get it to build and report back. Thanks @tonycoz

[scottchiefbaker]

I looked through this and it compiles and spits out appropriate PCG64 numbers. After some investigation it appears that most Perl installations use 8 byte NVs, which is essentially a double. Due to this, in order to produce less biased random floats, I think uint64_to_NV() should be changed to -53.

I have some minor white-space, and DEBUG clean-ups I'd like to land as part of this. Is there a way to submit a PR for this PR? Or how do I suggest changes?

Otherwise I think this looks really solid. Thanks for the hard work @tonycoz

[tonycoz]

I think uint64_to_NV() should be changed to -53.

This would lead to the bottom 11 bits of randomness being lost on builds with more precise NVs (I assume you want the shift back in or we won't get [0 .. 1) ).

What does changing to -53 fix? I don't see how it change the bias of the result - in both cases the high-bits of the result will be the same. double will have 53-bits of precision whether you remove the bottom 11 bits with a shift or the conversion from U64 to double discards them.

The only problem I can see with preserving those low bits for more precise NVs would be the slight difference in results, but I could see that preserving the bits reducing bias, ie. for floor(rand()*N) I'd expect the results to be (very very) slightly more evenly distributed (assuming PCG64 is evenly distributed)

I have some minor white-space, and DEBUG clean-ups I'd like to land as part of this. Is there a way to submit a PR for this PR? Or how do I suggest changes?

As mentioned in IRC, you could open a PR against my fork, or update your original PR.

[scottchiefbaker]

@tonycoz you're smart so I assume you know most of this, but I'm writing it all down for posterity for other people that have questions about generating random floats.

---

PRNGs only generate integers. Thus if you have a 64bit PRNG it generates integers between 0 and 2^64 -1. Perl wants to give out floats instead of giving out integers. To convert a random number to a float the math appears simple:

my $num   = rand64();
my $float = $num / (2 ** 64 - 1);

Due to the nature of doubles only being able to hold 53bits of mantissa (decimal values) this causes problems. The input has 2^64 potential values, but the output only has 2^53 potential values. This means that there are two input numbers that will generate the same output value. There is a small amount of bias because in those cases where there are duplicates there is a much higher chance of a particular random float coming out.

The traditional method ("Generating uniform doubles") of generating random floats is to only use 53bits so that the input to output is 1:1.

my $num   = rand64();
$num    >>= 11; # Use the most significant 53bits
my $float = $num / (2 ** 53 - 1);

[tonycoz]

my $num   = rand64();
$num    >>= 11; # Use the most significant 53bits
my $float = $num / (2 ** 53 - 1);

None of the examples on that page use / (2 ** N - 1) which is a little confusing, they all end up dividing by a power of two, not a (power of two) minus one. (dividing by $2^N-1$ would give us the range [0, 1] not the desired [0, 1))

The C example is:

 (x >> 11) * 0x1.0p-53

which has a different meaning to your expression, dividing by $2^{53}$

This means that there are two input numbers that will generate the same output value. There is a small amount of bias because in those cases where there are duplicates there is a much higher chance of a particular random float coming out.

With $num >> 11 / (2 ** 53) there's $2^{11}$ input values for each possible output value.

I suspect the issue is that for smaller input integers we get more possible output numbers for a given range of input, even if the [0, 1) range is still evenly distributed. And rounding might rear its ugly head too.

Unfortunately we don't have a constant like DBL_MANT_DIG (NVMANTBITS isn't quite right) which would let us make a smarter conversion, but maybe that can change.

[scottchiefbaker]

You are correct, I was off by one in my examples above. I used the correct algorithm in my updated PR.

[scottchiefbaker]

This would lead to the bottom 11 bits of randomness being lost on builds with more precise NVs (I assume you want the shift back in or we won't get [0 .. 1) ).

If the goal is to get every available random bit to the user (an admirable goal) then we shouldn't be using floats. 53bits of randomness is probably suitable for 99% of use cases. In the situation where the user needs more, we should expose the raw underlying PRNG to return uint64_t.

For the purposes of this PR I think that's beyond the scope.

[tonycoz]

#24105 now includes the relevant changes.