[Python-bugs-list] [ python-Bugs-476054 ] small improvement to random (original) (raw)

noreply@sourceforge.net noreply@sourceforge.net
Mon, 29 Oct 2001 10:00:03 -0800

Bugs item #476054, was opened at 2001-10-29 08:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476054&group_id=5470

Category: None Group: None

Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: small improvement to random

Initial Comment: there is this code in the random module:

        # Initialize from current time
        import time
        a = long(time.time() * 256)

iwouldn't it be better to use multiply by 1000000 since the microseconds are probably more random than the seconds?

-- erno@iki.fi

Comment By: Tim Peters (timone) Date: 2001-10-29 10:00

Message: Logged In: YES user_id=31435

The code has always done this, and I always assumed it was a good x-platform compromise. For example, on Windows time.time() % 1.0 can only take on 100 distinct values (it has only 1/100th second resolution), and is updated only about 18.2 times per second (it has only 0.055 second precision). The upshoot is that multiplying by 1e6 there would yield a long whose last 4 bits are always 0:

from time import time d = {} for i in xrange(1000000): ... t = time() * 1e6 ... t = int(long(t) & 0xff) ... d[t] = 1 ... len(d) 16 k = d.keys() k.sort() k map(hex, k) ['0x0', '0x10', '0x20', '0x30', '0x40', '0x50', '0x60', '0x70', '0x80', '0x90','0xa0', '0xb0', '0xc0', '0xd0', '0xe0', '0xf0']

That's worse than what the code does now (in short, ya, maybe microseconds are "more random", but only on boxes that have microsecond time() precision).

You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=476054&group_id=5470