[Tutor] Sum of Scores

[Luke Paireepinart]

Tiger12506 wrote:
>> bhaaluu wrote:
>>     
>>> Greetings,
>>>
>>> Beautiful! Thank you SO much for all the variations.
>>> I'm so sure I'll have much to learn from them. This
>>> is exactly the kind of stuff I'm currently studying.
>>>       
>
> I assume this is for me. Thank you kindly! :-)
>
>   
>>> I have a question for the list.
>>> After I posted my snippet, I added time to import,
>>> and a time.sleep(1) line to the code. The reason
>>> I did this is because I'm under the (possibly mistaken?)
>>> impression that random uses the computer
>>> time as a random number generator 'seed',
>>> for generating pseudo-random numbers?
>>>
>>>       
>> It uses time, it may also use other things.
>> However, this is only to initialize the random number generator.
>> You only need one seed and from that you can generate an infinitely long
>> string of pseudo-random numbers.
>>     
>
> Not infinitely long. From the docs -
>
> [Quote]
> Almost all module functions depend on the basic function random(), which 
> generates a random float uniformly in the semi-open range [0.0, 1.0). Python 
> uses the Mersenne Twister as the core generator. It produces 53-bit 
> precision floats and has a period of 2**19937-1. The underlying 
> implementation in C is both fast and threadsafe. The Mersenne Twister is one 
> of the most extensively tested random number generators in existence. 
> However, being completely deterministic, it is not suitable for all 
> purposes, and is completely unsuitable for cryptographic purposes.
> [/Quote]
>
> So only if you use the random functions
> 4.3154247973881626480552355163379e+6001
> times would the pattern repeat itself. Until then, you're safe. ;-)
>   
Well, I was trying to emphasize that it was, for pretty much all intents 
and purposes, infinite.
via timeit, my computer can perform approximately 4000000 
random.random()s per second.
 >>> x = timeit.Timer('random.random()','import random')
 >>> x.timeit(4000000)
1.0523957653835794

4*10**6001 / 4*10**6 is still 10**5095 seconds before the period is 
repeated (and remember this is when i'm trying to cause a repetition, 
not using the module normally!)
The relationship between seconds and years is
 >>> 60*60*24*365.25
31579200.0
i.e. 60 seconds to a minute, 60 minutes to an hour, 24 hours to a day, 
and 365.25 days per year.

Therefore, it would take my computer
 >>> (10**5095) / int(60*60*24*365.25)
years (which is too long to post in this e-mail)
in fact, it's so large I am having a hard time believing I didn't make a 
mistake in my calculations somewhere.
somewhere on the order of a centillion**quadrillion years.
(a centillion is 10**303 or
100000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
0000 and a quadrillion is 10**15 or 1000000000000000.
In other words, approx. (very approximately :)) 10**4545 years)
Because the possibility of my computer even existing after that long is 
effectively zero, I consider the pattern to never repeat :)
>> In other words, the only way you'd end up getting the same value is if
>> you ran the program, quit it, then ran it again, in less than a second.
>> (or possibly reloaded the module)
>>     
>
> This freaked me out for a bit with a c program I wrote a while back. It was 
> a screen saver built upon random values. I would double click its icon, and 
> accidently jerk the mouse, double click it again. I thought I noticed that 
> the two screens were the same. A little research brought me to that tidbit 
> of information.
>
> I'm not sure if reloading the module would or not. I would think that the 
> seeding of the generator would occur at import of the random module. In 
> which case, it would only happen once because import modules are not 
> imported twice in the same session. (see recent threads)
>   
by reloading I didn't mean importing it again.
I meant reload()ing it.
Well, we can test this pretty easily.

 >>> import random
 >>> for x in range(10):
    reload(random)
    print random.random()

   
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.322316243317
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.223659531704
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.991195051657
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.0349410934903
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.586833655938
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.0090626236054
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.0650813786008
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.198508992645
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.0567290580105
<module 'random' from 'C:\Python24\lib\random.pyc'>
0.0446836944247


Nope, I guess reloading it doesn't cause it to reuse the same seed.
See, I thought reload was just a forced 'import'.
But maybe it has some complexity behind it, as per it not reloading() if 
the module hasn't changed?
The docstring isn't a whole lot of help on this:
 >>> help(reload)
Help on built-in function reload in module __builtin__:

reload(...)
    reload(module) -> module
   
    Reload the module.  The module must have been successfully imported 
before.