[Python-bugs-list] [ python-Bugs-690083 ] test_random fails sometimes
SourceForge.net
noreply@sourceforge.net
Thu, 20 Feb 2003 09:22:50 -0800
Bugs item #690083, was opened at 2003-02-20 16:07
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690083&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_random fails sometimes
Initial Comment:
>> test test_random failed -- Traceback (most recent
call last):
>> File
"/home/lemburg/projects/Python/Dev-Python/Lib/test/test_random.py",
line 25, in test_autoseed
>> self.assertNotEqual(state1, state2)
>> File
"/home/lemburg/projects/Python/Dev-Python/Lib/unittest.py",
line 300, in failIfEqual
>> raise self.failureException, \
>> AssertionError: (2, (1045703145, 318847470,
620640488, 320379787, -1732263717, -1278593374, ...
>
>
>
> This one I don't understand. Maybe the sleep(1) in
the test isn't
> long enough?
I could not reproduce this, but perhaps using
long(time.time()*256) isn't
safe enough to produce different states in the
WH-generator ?! I'd
add a counter or hash the previous stored state to add some
more noise.
----------------------------------------------------------------------
>Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-20 18:22
Message:
Logged In: YES
user_id=38388
Tim, no I'm not sure that it's the WH seed method causing
this. I was basically just guessing here from looking at the
code in random.py.
You could be right in that the time() C function used in _random
is causing the problem.
I'll check with a time.sleep(0.01) call instead of
time.sleep(1).
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-02-20 17:38
Message:
Logged In: YES
user_id=31435
MAL, do you know that this failed during the WH part of the
test? The WH seed() guarantees to produce distinct states
given distinct inputs, and time.time() all by itself should be
enough so that it's significantly different between time.sleep
(1) calls. Multiplying by 256 is just gravy, getting some
benefit from the fractional seconds too.
The Twister's idea of time-based seeding uses the C time()
function, though, and that's less robust because it doesn't
produce "fractional seconds" (as time.time() produces, as
well as it can). But it should still be at least a second
different, unless your system clock got fiddled between calls
(so, e.g., do you use some web-based time synch service to
keep your clock up to date?).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=690083&group_id=5470