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.
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
