This code generates very non-random numbers, even when the seed value is reinitialized. Take a look at the first number in each run ! Is this right ? -- JFØ #!/usr/local/bin/python2.1 # Python Virtual clock import RandomArray print "Seed", RandomArray.get_seed() for i in range(1000000,10000000,1000000): print "Clock at time:" , i/1000000, ":", RandomArray.normal(10,2) [root@blekkulf /root]# ./t2.py Seed (101743, 1951) Clock at time: 1 : 7.98493051529 Clock at time: 2 : 10.8439420462 Clock at time: 3 : 7.59234881401 Clock at time: 4 : 7.32021093369 Clock at time: 5 : 10.9444898367 Clock at time: 6 : 10.1128772199 Clock at time: 7 : 13.1178274155 Clock at time: 8 : 11.779414773 Clock at time: 9 : 10.7529922128 [root@blekkulf /root]# ./t2.py Seed (101743, 1953) Clock at time: 1 : 7.98525762558 Clock at time: 2 : 9.38142818213 Clock at time: 3 : 7.11979293823 Clock at time: 4 : 10.867649436 Clock at time: 5 : 9.62882992625 Clock at time: 6 : 12.1940765381 Clock at time: 7 : 6.84895467758 Clock at time: 8 : 8.13472533226 Clock at time: 9 : 8.15638375282 [root@blekkulf /root]# ./t2.py Seed (101743, 1959) Clock at time: 1 : 7.98623776436 Clock at time: 2 : 14.5040078163 Clock at time: 3 : 11.3408681154 Clock at time: 4 : 6.32757425308 Clock at time: 5 : 8.94617521763 Clock at time: 6 : 12.1802353859 Clock at time: 7 : 12.0685124397 Clock at time: 8 : 10.5330892205 Clock at time: 9 : 10.9744755626
Johan Fredrik Øhman wrote:
This code generates very non-random numbers, even when the seed value is reinitialized. Take a look at the first number in each run !
The first numbers in each of your three runs are 7.98493051529 , 7.98525762558 and 7.98623776436. They look like different numbers to me. If you want the difference between initial values to be greater, you need to make the difference in your seeds greater. For example, if I run your code now, I get 8.29225027561, 8.29484963417 and 8.29744851589, but setting the seed to (1,2) gives an initial value of 5.69397783279. Remember, these are only pseudorandom numbers. Tim C
Is this right ?
-- JFØ
#!/usr/local/bin/python2.1
# Python Virtual clock import RandomArray
print "Seed", RandomArray.get_seed() for i in range(1000000,10000000,1000000): print "Clock at time:" , i/1000000, ":", RandomArray.normal(10,2)
[root@blekkulf /root]# ./t2.py Seed (101743, 1951) Clock at time: 1 : 7.98493051529 Clock at time: 2 : 10.8439420462 Clock at time: 3 : 7.59234881401 Clock at time: 4 : 7.32021093369 Clock at time: 5 : 10.9444898367 Clock at time: 6 : 10.1128772199 Clock at time: 7 : 13.1178274155 Clock at time: 8 : 11.779414773 Clock at time: 9 : 10.7529922128 [root@blekkulf /root]# ./t2.py Seed (101743, 1953) Clock at time: 1 : 7.98525762558 Clock at time: 2 : 9.38142818213 Clock at time: 3 : 7.11979293823 Clock at time: 4 : 10.867649436 Clock at time: 5 : 9.62882992625 Clock at time: 6 : 12.1940765381 Clock at time: 7 : 6.84895467758 Clock at time: 8 : 8.13472533226 Clock at time: 9 : 8.15638375282 [root@blekkulf /root]# ./t2.py Seed (101743, 1959) Clock at time: 1 : 7.98623776436 Clock at time: 2 : 14.5040078163 Clock at time: 3 : 11.3408681154 Clock at time: 4 : 6.32757425308 Clock at time: 5 : 8.94617521763 Clock at time: 6 : 12.1802353859 Clock at time: 7 : 12.0685124397 Clock at time: 8 : 10.5330892205 Clock at time: 9 : 10.9744755626
The first numbers in each of your three runs are 7.98493051529 , 7.98525762558 and 7.98623776436. They look like different numbers to me. First, thanks for your answer Time. I do agree, they are different. But I wouldn't call it random. I didn't expect that the small difference in the initial seed would affect the first number with so little. Usually the seed numbers I have experienced other places have much more dramatic effect on the numbers, if you see what I mean... If you want the difference between initial values to be greater, you need to make the difference in your seeds greater. For example, if I run your code now, I get 8.29225027561, 8.29484963417 and 8.29744851589, but setting the seed to (1,2) gives an initial value of 5.69397783279. Remember, these are only pseudorandom numbers. Yes, they are pseudorandom and that is OK. What I just want is some more initial difference between the runs without setting the seed number manually. But know I know this is not a flaw in the RNG, but "its the way it is supposed to be" Thanks -- Johan Fredrik Ohman
Johan Fredrik Øhman wrote:
The first numbers in each of your three runs are 7.98493051529 , 7.98525762558 and 7.98623776436. They look like different numbers to me.
First, thanks for your answer Time. I do agree, they are different. But I wouldn't call it random. I didn't expect that the small difference in the initial seed would affect the first number with so little. Usually the seed numbers I have experienced other places have much more dramatic effect on the numbers, if you see what I mean...
OK, you need to use Konrad Hinsen's excellent RNG module which comes with Numeric Python: ################################# # Python Virtual clock import RNG dist = RNG.NormalDistribution(10, 2) rng = RNG.CreateGenerator(0, dist) for i in range(1000000,10000000,1000000): print "Clock at time:" , i/1000000, ":", rng.ranf() ################################## The above code gives 8.46183655136, 7.29889782477 and 5.58243682462 as the first values in three successive runs on my system. Hope this helps, Tim C
If you want the difference between initial values to be greater, you need to make the difference in your seeds greater. For example, if I run your code now, I get 8.29225027561, 8.29484963417 and 8.29744851589, but setting the seed to (1,2) gives an initial value of 5.69397783279. Remember, these are only pseudorandom numbers.
Yes, they are pseudorandom and that is OK. What I just want is some more initial difference between the runs without setting the seed number manually. But know I know this is not a flaw in the RNG, but "its the way it is supposed to be"
Thanks
-- Johan Fredrik Ohman
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
About random number generation with Numeric: a. IMHO, RNG is the right choice if you are picky about the quality of the generator. This generator has a long history of heavy use. RandomArray is in the core because someone put it there early, not because it is the best. I do not claim to be an authority on this but that is my understanding. b. The suggestion made by one correspondent, that a generator should generate and throw away one value when the seed is set, sounds correct if viewed from the point of view of the initial set of a single stream. But many users need multiple streams that are independent and reproducible. This is done by saving the state of the generator and then restoring it later. It is important that this save/restore not change the results compared to not doing it. The presence or absence of another computation, or frequency of dump/restarts, that require a save/restore, must not affect the result. Thus a decision to throw away a result must come from the application level.
participants (3)
-
Johan Fredrik Øhman -
Paul F Dubois -
Tim Churches