[issue44080] Bias in random.choices(long_sequence)

Raymond Hettinger added the comment: FWIW, the principal use case that choices() was designed for is resampling/bootstapping. In that use case, speed matters and small imbalances in large sequences don't matter at all. Also, the API was designed to make it easy to select from an itemized

[issue44080] Bias in random.choices(long_sequence)

Raymond Hettinger added the comment: This is known and an intentional design decision. It isn't just a speed issue. Because the weights can be floats, we have floats involved at the outset and some round-off is unavoidable. To keep the method internally consistent, the same technique is

[issue44080] Bias in random.choices(long_sequence)

Dennis Sweeney added the comment: Your suspicion looks correct, random() is faster: .\python.bat -m pyperf timeit -s "from random import choices" "choices(range(100), k=10_000)" Before int_choices.diff: Mean +- std dev: 1.49 ms +- 0.09 ms After int_choices.diff: Mean +- std dev: 3.50 ms +-

[issue44080] Bias in random.choices(long_sequence)

Mark Dickinson added the comment: This is similar to #9025 (for randrange), and in principle the random.choices case without explicit weights could be fixed similarly. But I'm not sure it's worth it, for a couple of reasons: - The problem only really affects "virtual" population sequences

[issue44080] Bias in random.choices(long_sequence)

Change by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44080] Bias in random.choices(long_sequence)

New submission from Dennis Sweeney : Problem: Random.choices() never returns sequence entries at large odd indices. For example: >>> import random >>> [x % 2 for x in random.choices(range(2**53), k=20)] [0, 0, 0, 0, 1, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 1, 1, 1, 0, 1] >>> [x % 2 for x in