Tim Peters added the comment:
I've been involved - usually very lightly, but sometimes deeply - with PRNGs
for over 40 years. I've never seen anyone raise the kinds of concerns you're
raising here, and, frankly, they don't make sense to me.
But on the chance that I've missed recent
jfbu added the comment:
"bug" is a strong word, which I did never employ myself, apart from using this
channel of report. I rather think of a (non-documented) "deficiency", but I
expect the consensus will again be that I am expressing a "raw expression".
However reading more than once that
Raymond Hettinger added the comment:
I concur with Tim and Mark. This isn't a bug. The randomization occurs at the
getrandbits() level. The downstream functions, such as randbelow and
randrange, have no responsibility to create additional dispersion; instead,
their role is to map the
Tim Peters added the comment:
This is where you're not getting traction:
"A randrange() function should a priori not be so strongly tied to the binary
base."
That's a raw assertion. _Why_ shouldn't it be? "Because I keep saying so"
isn't changing minds ;-)
I understand you're looking at
jfbu added the comment:
@tim.peters yes, a uniform random variable rescaled to two nearby scales N and
M will display strong correlations. The CPython randrange() exhibits however
orders of magnitude higher such correlations, but only in relation to a common
bitlength. A randrange()
Tim Peters added the comment:
Sorry, I don't see "a problem" here either. Rounding instead can change the
precise nature of the correlations if you insist on starting from the same
seed, but it hardly seems a real improvement; e.g.,
>>> random.seed(12)
>>> [round(random.random() * 100) for
jfbu added the comment:
Yes indeed the source code of _randbelow_with_getrandbits generates this
effect. And I understand the puzzlement about my test file setting the same
random seed and then complaining about correlations. But there is some
non-uniformity which is enormous between what
Mark Dickinson added the comment:
These results are hardly surprising, given the algorithms used. But why would
you consider this a problem?
If you want your randrange(n) and randrange(m) results to be independent, don't
generate them from the exact same random source, starting with the
New submission from jfbu :
We generate quadruples of random integers using randrange(n) and randrange(m)
and count how many times the quadruples are identical, using the same random
seed. Of course for nearby n and m (the real life example was with n==95 and
m==97) we do expect matches. But
