Comment by thaumasiotes
7 hours ago
That sounds like a pretty strong source of true randomness, frankly.
(It's then filtered through the list, so the list needs to have good pseudorandomness properties anyway, but still.)
7 hours ago
That sounds like a pretty strong source of true randomness, frankly.
(It's then filtered through the list, so the list needs to have good pseudorandomness properties anyway, but still.)
> (It's then filtered through the list, so the list needs to have good pseudorandomness properties anyway, but still.)
Not sure? Suppose your list only had two number 0 and 1, and you build your random numbers one bit at a time.
Or more realistically, you have 256 numbers on the list 0, 1, 2, ..., 255 in order. If the 'large numbers of players drawing from the same list' assumption holds, it doesn't matter much that the list is in order.
What's just a bit weird is why anyone would want to turn an embarrassingly parallel problem into something with a sequential bottleneck?
> Or more realistically, you have 256 numbers on the list 0, 1, 2, ..., 255 in order. If the 'large numbers of players drawing from the same list' assumption holds, it doesn't matter much that the list is in order.
Why not? That should convert your random number generation into draws from a Poisson process. If you were looking to simulate a Poisson distribution, you're set. If not, you probably just ruined your RNG.
(If the idea is that the interval between any two samples is so large that the list will inevitably be cycled several times before any one person can sample a second byte, there's something to that. It's going to make asking for random numbers more than 8 bits long challenging though.)
> It's going to make asking for random numbers more than 8 bits long challenging though.
'Yield' to other players' threads or processes after each byte you draw.