From: Tim Peters Date: Tue, 31 Aug 2004 02:19:55 +0000 (+0000) Subject: HardwareRandom: Go back to multiplying by 2**-BPF instead of using X-Git-Tag: v2.4a3~42 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=7c2a85b2d44851c2442ade579b760f86447bf848;p=python 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 fd9374a7f1..0047c9137a 100644 --- a/Lib/random.py +++ b/Lib/random.py @@ -43,7 +43,7 @@ from warnings import warn as _warn 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 @@ TWOPI = 2.0*_pi 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 @@ class HardwareRandom(Random): """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."""