"No, four parts: one small village still holds out against the invaders." (Presumably the NaNs)
the C standard says that [using a union] is undefined behaviour
I thought that was fixed? C99 TC3 introduced a footnote in ยง6.5.2.3 which says
If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.
which says to me that you take responsibility for knowing how your integers match up to your float on the target platform, but once you've got that right, the compiler isn't allowed to just throw your code away.
Why isn't it better to just return pcg64_random(rng) * 0x1.0p-64? Then even if the high 11 bits of the value are zero, you still get a full mantissa's worth of randomness.
Even better, go back to the bit-hacking approach, and set all 52 mantissa bits to random values, and set the exponent to 0x3fe - __builtin_clz64(pcg64_random())? Then your exponent can go all the way down to -64, and you still have a full mantissa even at the low end.
Ideally you'd want solution that would deliver a full mantissa of random bits no matter what the exponent, even in the ultra-improbable event that it's -1023 or something! That's in the spirit of IEEE 754, which normally takes the view that you should return the answer that arises from taking the true mathematical value of the result and rounding it to the nearest value in the target precision. In the case where the true value is random this takes a bit of interpretation, but I think "generate FP bit patterns with the same probability distribution as you'd get from rounding genuinely random real numbers to double" is surely the Platonically-right interpretation. And there's no part of that definition that would agree that below some arbitrary exponent threshold all mantissa bits are zero :-P
But if you want to go further than an exponent of -64 then I think you need a lot more random input data...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2023-06-23 21:42 (UTC)"No, four parts: one small village still holds out against the invaders." (Presumably the NaNs)
the C standard says that [using a union] is undefined behaviour
I thought that was fixed? C99 TC3 introduced a footnote in ยง6.5.2.3 which sayswhich says to me that you take responsibility for knowing how your integers match up to your float on the target platform, but once you've got that right, the compiler isn't allowed to just throw your code away.
return((double)(pcg64_random(rng) >> 11) * 0x1.0p-53);Why isn't it better to just return
pcg64_random(rng) * 0x1.0p-64? Then even if the high 11 bits of the value are zero, you still get a full mantissa's worth of randomness.Even better, go back to the bit-hacking approach, and set all 52 mantissa bits to random values, and set the exponent to
0x3fe - __builtin_clz64(pcg64_random())? Then your exponent can go all the way down to -64, and you still have a full mantissa even at the low end.Ideally you'd want solution that would deliver a full mantissa of random bits no matter what the exponent, even in the ultra-improbable event that it's -1023 or something! That's in the spirit of IEEE 754, which normally takes the view that you should return the answer that arises from taking the true mathematical value of the result and rounding it to the nearest value in the target precision. In the case where the true value is random this takes a bit of interpretation, but I think "generate FP bit patterns with the same probability distribution as you'd get from rounding genuinely random real numbers to
double" is surely the Platonically-right interpretation. And there's no part of that definition that would agree that below some arbitrary exponent threshold all mantissa bits are zero :-PBut if you want to go further than an exponent of -64 then I think you need a lot more random input data...