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.
fanf2 9 hours ago [-]
I prefer zooming for reading code. Horizontal scrolling divs are horrible.
Etheryte 8 hours ago [-]
But then you still end up scrolling horizontally once you're zoomed in, no? What's the difference?
7 hours ago [-]
fanf2 4 hours ago [-]
I can zoom out.
rewqa 10 hours ago [-]
[flagged]
Rendered at 21:55:58 GMT+0000 (UTC) with Wasmer Edge.
[1] https://github.com/lemire/fastrange
[2] https://github.com/swiftlang/swift/pull/39143
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
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.