Why not use regular rejection sampling when `limit` is known at compile-time.
Does fastrange[1] have fewer rejections due to any excess random bits[2]?
Fastrange is slightly biased because, as Steve Canon observes in that Swift PR, it is just Knuth’s multiplicative reduction. The point of this post is that it’s possible to simplify Lemire’s nearly-divisionless debiasing when the limit is known at compile time.
The code blocks break mobile viewport width. Surely it's better than wrapping, but the best solution is to use max-width and overflow-x: auto which makes them scrollable.
Why not use regular rejection sampling when `limit` is known at compile-time. Does fastrange[1] have fewer rejections due to any excess random bits[2]?
[1] https://github.com/lemire/fastrange
[2] https://github.com/swiftlang/swift/pull/39143
What do you mean by “regular” rejection sampling?
Fastrange is slightly biased because, as Steve Canon observes in that Swift PR, it is just Knuth’s multiplicative reduction. The point of this post is that it’s possible to simplify Lemire’s nearly-divisionless debiasing when the limit is known at compile time.
I previously experimented with really-divisionless debiasing but I was underwhelmed with the results https://dotat.at/@/2022-04-20-really-divisionless.html
> “regular” rejection sampling
I was thinking naive: mask off unwanted bits then reject any value above the limit.
It would seem like https://c-faq.com/lib/randrange.html would also move the multiply --or divide by constant-- out of the loop.
The code blocks break mobile viewport width. Surely it's better than wrapping, but the best solution is to use max-width and overflow-x: auto which makes them scrollable.
I prefer zooming for reading code. Horizontal scrolling divs are horrible.
But then you still end up scrolling horizontally once you're zoomed in, no? What's the difference?
I can zoom out.
[flagged]