[Python-bugs-list] [ python-Bugs-690083 ] test_random fails sometimes
SourceForge.net
noreply@sourceforge.net
Thu, 20 Feb 2003 17:51:14 -0800
Bugs item #690083, was opened at 2003-02-20 10: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: Closed
>Resolution: Fixed
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: Raymond Hettinger (rhettinger)
Date: 2003-02-20 20:51
Message:
Logged In: YES
user_id=80475
Checked in a Lib/test/test_random.py 1.9.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-20 15:02
Message:
Logged In: YES
user_id=80475
The test verifies that time.time() is being called when no
seed is provided. We've shown that is true. The issues of
timer resolution appear to be just an interesting
distraction, so Tim's simple time.sleep(1.1) approach
looks best to me.
I'll use 1.11 just to make sure this bug stays dead.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-02-20 13:50
Message:
Logged In: YES
user_id=31435
datetimemodule.c contains a little routine time_time(), which
imports the time module and calls time.time(), returning the
result as a Python float. As the comment above it says,
maybe it would be better to make this part of Python's C API
(time.time() plays a lot of platform-specific tricks to get better-
than-second resolution when possible).
OTOH, sticking time.sleep(1.1) in the test case would
probably fix it too.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-20 12:58
Message:
Logged In: YES
user_id=38388
Seconds are longer in Old Europe :-)
Seriously, I don't know how time.sleep() is implemented by the
C lib or the kernel. Could be that time.sleep(1) sometimes only
waits 0.99 seconds or that C libs time() uses some counter which
isn't always updated in exact one second intervals.
I'd suggest to use the same clock source used in the time module
for better accuracy rather than relying on _random's seed() to
provide it's own C lib time() based one.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2003-02-20 12:32
Message:
Logged In: YES
user_id=31435
I expect that time.sleep(0.01) would cause the Twister test to
fail (on average) 99 times per 100.
For some reason we don't understand then, two calls to C
time() returned the same value despite an intervening Python
time.sleep(1) call. Has there been a leap second lately
<wink>?
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-20 12:27
Message:
Logged In: YES
user_id=38388
Using time.sleep(0.01) causes the test to always fail on my
machine
and instrumenting the code with a print reveals that it's indeed
the _random code failing:
test_autoseed (__main__.MersenneTwister_TestBasicOps) ...
Running class <class '__main__.MersenneTwister_TestBasicOps'>
FAIL
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-02-20 12: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 11: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