versus generator period. While this was a real weakness of the
older WH generator for lists with just a few dozen elements,
and so could potentially bite the naive ;-), the Twister should
show excellent behavior up to at least 600 elements.
Module docstring: reflowed some jarringly short lines.
Renamed the new generator at Trevor's recommendation.
The name HardwareRandom suggested a bit more than it
delivered (no radioactive decay detectors or such).
ldexp. Both methods are exact, and return the same results. Turns out
multiplication is a few (but just a few) percent faster on my box.
They're both significantly faster than using struct with a Q format
to convert bytes to a 64-bit long (struct.unpack() appears to lose due
to the tuple creation/teardown overhead), and calling _hexlify is
significantly faster than doing bytes.encode('hex'). So we appear to
have hit a local minimum (wrt speed) here.
components without division and without roundoff error for properly
sized mantissas (i.e. on systems with 53 or more mantissa bits per
float). Eliminates the previous implementation's rounding bias as
aptly demonstrated by Tim Peters.
* Added C coded getrandbits(k) method that runs in linear time.
* Call the new method from randrange() for ranges >= 2**53.
* Adds a warning for generators not defining getrandbits() whenever they
have a call to randrange() with too large of a population.
random.sample() uses one of two algorithms depending on the ratio of the
sample size to the population size. One of the algorithms accepted any
iterable population argument so long as it defined __len__(). The other
had a stronger requirement that the population argument be indexable.
While it met the documentation specifications which insisted that the
population argument be a sequence, it made random.sample() less usable
with sets. So, the second algorithm was modified to coerce non-indexable
iterables and dictionaries into a tuple before proceeding.
The default seed is time.time().
Multiplied by 256 before truncating so that fractional seconds are used.
This way, two successive calls to random.seed() are much more likely
to produce different sequences.
some of this code because useless, and (worse) could return a long
instead of int (in Zope that's important, because a long can't be used
as a key in an IOBTree or IIBTree).
It was once available so that faster generators could be substituted. Now,
that is less necessary and preferrably done via subclassing.
Also, clarified and shortened the comments for sample().
Added design notes in comments.
Used better variable names.
Eliminated the unsavory "pool[-k:]" which was an aspiring bug (for k==0).
Used if/else to show the two algorithms in parallel style.
Added one more test assertion.
Loosened the acceptable 'start' and 'stop' arguments so that any
Python (bounded) ints can be used. So, e.g., randrange(-sys.maxint-1,
sys.maxint) no longer blows up.
and the .seed() and .whseed() methods failed to reset it. In other
words, setting the seed didn't completely determine the sequence of
results produced by random.gauss(). It does now. Programs repeatedly
mixing calls to a seed method with calls to gauss() may see different
results now.
Bugfix candidate (random.gauss() has always been broken in this way),
despite that it may change results.
Tim Peters
Raymond Hettinger
Jeremy Hylton
Andrew M. Kuchling
Guido van Rossum
Neal Norwitz