This is exactly what the linked python code is doing, right? Just retrying the random call if the sampled value is outside of the acceptable range (adjusted for the fact that Python generally makes random numbers only available between 0-1).
So for my simple coin flipping app, i have the choice between doing it right, and using up more of the randomness my computer has stored suring runtim, or doing it wrong, and by the end of human existence, the coin will have come up heads once too often. I think this isn’t something terribly problematic. Still an interesting read though.
Also, I don’t know that much about how the computer creates random numbers, but how certain can we be that the original random call actually is uniformely distributed to begin with?
Ugh, getting back to properly distributed random from the FP representation is almost as annoying as generating them properly in the first place. I have a recollection that most approaches now only give you 27/53 bits of entropy due to the misery of dealing with over representation of more heavily fractional values. Essentially generate a random value between 1 and 2 (which is easy in a bitwise manner) and then subtract 1.
This is exactly what the linked python code is doing, right? Just retrying the random call if the sampled value is outside of the acceptable range (adjusted for the fact that Python generally makes random numbers only available between 0-1).
So for my simple coin flipping app, i have the choice between doing it right, and using up more of the randomness my computer has stored suring runtim, or doing it wrong, and by the end of human existence, the coin will have come up heads once too often. I think this isn’t something terribly problematic. Still an interesting read though.
Also, I don’t know that much about how the computer creates random numbers, but how certain can we be that the original random call actually is uniformely distributed to begin with?
score 1 · canonical
Ugh, getting back to properly distributed random from the FP representation is almost as annoying as generating them properly in the first place. I have a recollection that most approaches now only give you 27/53 bits of entropy due to the misery of dealing with over representation of more heavily fractional values. Essentially generate a random value between 1 and 2 (which is easy in a bitwise manner) and then subtract 1.
score 1 · canonical