[Python-bugs-list] [ python-Bugs-690083 ] test_random fails sometimes

[SourceForge.net]

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: 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: 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