[Python-bugs-list] [ python-Bugs-476054 ] small improvement to random

[noreply@sourceforge.net]

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 (tim_one)
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