summaryrefslogtreecommitdiff
path: root/numpy/lib/arraysetops.py
diff options
context:
space:
mode:
authorWarren Weckesser <warren.weckesser@gmail.com>2019-10-24 22:03:05 -0400
committerWarren Weckesser <warren.weckesser@gmail.com>2019-10-24 22:06:31 -0400
commit4780c1bc78065154e2817e899a37acdde7225ec5 (patch)
treec39d5ff2ad634fe3244dfff358460ba2cbdb1569 /numpy/lib/arraysetops.py
parent34e83881a9e377d8cc8fe2644bfb06600d9e77d1 (diff)
downloadnumpy-4780c1bc78065154e2817e899a37acdde7225ec5.tar.gz
BUG: random: biased samples from integers() with 8 or 16 bit dtype.
When an 8 or 16 bit dtype was given to the integers() method of the Generator class, the resulting sample was biased. The problem was the lines of the form const uint8_t threshold = -rng_excl % rng_excl; in the implementations of Lemire's method, in the C file distributions.c. The intent was to compute (UINT8_MAX+1 - rng_excl) % rng_excl However, when the type of rng_excl has integer conversion rank lower than a C int (which is almost certainly the case for the 8 and 16 bit types), the terms in the expression -rng_excl % rng_excl are promoted to int, and the result of the calculation is always 0. The fix is to make the expression explicit, and write it as const uint8_t threshold = (UINT8_MAX - rng) % rng_excl; rng is used, because rng_excl is simply rng + 1; by using rng, we we only need the constant UINT#_MAX, without the extra +1. For consistency, I made the same change for all the data types (8, 16, 32 and 64 bit). Closes gh-14774.
Diffstat (limited to 'numpy/lib/arraysetops.py')
0 files changed, 0 insertions, 0 deletions