HardwareRandom: Go back to multiplying by 2**-BPF instead of using
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.
diff --git a/Lib/random.py b/Lib/random.py
index fd9374a..0047c91 100644
--- a/Lib/random.py
+++ b/Lib/random.py
@@ -43,7 +43,7 @@
from types import MethodType as _MethodType, BuiltinMethodType as _BuiltinMethodType
from math import log as _log, exp as _exp, pi as _pi, e as _e
from math import sqrt as _sqrt, acos as _acos, cos as _cos, sin as _sin
-from math import floor as _floor, ldexp as _ldexp
+from math import floor as _floor
__all__ = ["Random","seed","random","uniform","randint","choice","sample",
"randrange","shuffle","normalvariate","lognormvariate",
@@ -57,6 +57,7 @@
LOG4 = _log(4.0)
SG_MAGICCONST = 1.0 + _log(4.5)
BPF = 53 # Number of bits in a float
+RECIP_BPF = 2**-BPF
try:
from os import urandom as _urandom
@@ -759,7 +760,7 @@
"""Get the next random number in the range [0.0, 1.0)."""
if _urandom is None:
raise NotImplementedError('Cannot find hardware entropy source')
- return _ldexp(long(_hexlify(_urandom(7)), 16) >> 3, -BPF)
+ return (long(_hexlify(_urandom(7)), 16) >> 3) * RECIP_BPF
def getrandbits(self, k):
"""getrandbits(k) -> x. Generates a long int with k random bits."""