I'm just curious if there are any particular reasons why the Random API's next(upperBound: T) is implemented the way it is (with two `%`

) rather than using the AFAICS more efficient "Apple's Method" (with a bitmask and no `%`

) as described eg here.

1 Like

Is `upperBound`

required to be a power of two here? Because otherwise this implementation seems not-quite-right…

It's a little bit subtle to implement efficiently for generic integers that may be arbitrarily large, but mostly I/we simply haven't gotten around to it yet, and the current implementation is "good enough"--there have been higher-priority optimization tasks to attend to.

3 Likes

No, it's simple rejection sampling, so easy to prove that it's always correct.

1 Like

Right, what got me is the fact that it rejects the *initial* range which occurs one time more than every other value before the final modulo.

1 Like