I found out that case turned out wrong...
more random meaning less bias = less predictability. for every PRNG, observing a certain number of elements reveals the trend and allows one to predict all subsequent elements. that number is 624 for mersenne MT19937.
so a 'more' random PRNG would have a higher such number.
of course, mersenne's output is already 'random' enough for our purposes, but i was wondering if coupling it with rand() would decrease the bias. this was a purely conceptual question. i hear what you are saying about rand() simply spitting out a value based on srand()'s seed, but unless we know how the srand()/rand() algorithm works, i dont think its possible to say whether coupling PRNGs and multiple seeding will or won't decrease bias.
Look, I think we've already given you an idea on how rand() works.
Rand takes a number and applies an algorithm on that number to produce varying results from that number. But what is that "number" I'm mentioning? That's what you pass to srand.
How exactly does rand() work in a in-depths tutorial? I'm afraid I can't answer that either because it's implementation dependant. Every compiler can implement it in a different way.
Heck, even the above is speculation, because how rand() produces a random number isn't defined--it's up to the designers of the implementation for their compiler to make up how that works, so long as it returns a random number from the seed.
wow, you sure are passionate about your srand(), lol.
i don't see how re-seeding it would decrease the period based on what you said. all re-seeding does is resets the period. that doesn't necessarily imply that you are shortening the period. even if you get repetitions, thats ok since repetitions are expected in a truly random sequence. but theres nothing to say that you would get the "last few results to be repeated identically", which is obviously bad.
anyway, like I said, I call srand() over for each iteration. And in my QRBG thread, I mentioned that I called srand() once for each iteration of a 10,000 iterations loop. By doing so, I was able to get the bell curve for the probability distribution of twin dice tosses, with numerical probabilities extremely close to the predicted. Since I was coupling with the mersenne, I have no doubt that caling srand() just once would have probably yielded similar results. But this is a great indication that calling srand() multiple times doesn't have any adverse effects.
Are you listening? Calling srand several times destroys the randomability.
If you doubt us, then why are you here asking for advice?
If you don't want our advice or listen to out advice, then why are you here?
But since you obviously fail to see the difference, here's some statistics for you.
Here are samples (25 iterations, 1 second delay, srand called on each iteration):
2406
2409
2412
2416
2419
2422
2426
2429
2432
2435
2439
2442
2445
2448
2452
2455
2458
2461
2465
2468
2471
2475
2478
2481
2484
Here are samples (25 iterations, 0 second delay, srand called once):
2181
5570
7297
29776
625
19023
17188
12741
15153
15603
17361
6201
30635
15432
6854
15035
10045
16518
19564
1253
23726
20648
17895
26905
21349
Tell me which one is more random.
> i called srand() 10,000 times in a single program and it did nothing to "destroy the randomability". that pretty much kills your argument.
But your argument would be that calling it many times improves the randomness, and it doesn't.
Because there is no way to know the implementation of the standard rand() / srand() functions, it's impossible to say what the effect of calling srand() many times with very similar seed values (say incrementing time) would be. Sure you may see nothing untoward, but other people (with other implementations) would see something far different.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
First test scenario:
Second test scenario:Code:int main() { srand( time(NULL) ); for (int i = 0; i < 25; i++) cout << rand() << endl; }
And for the sake of it, if I remove the sleep and call srand inside the loop, I get this:Code:int main() { for (int i = 0; i < 25; i++) { srand( time(NULL) ); cout << rand() << endl; Sleep(1000); } }
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
2285
Elysia, shawnt was seeding srand with a random number generated from a Mersenne Twister PRNG. So with a random seed, the output of rand() will be much more random than with your example.
I still don't see how combining the two helps in any way, but I'm not sure shawnt does either, he's just hoping.
True, but it shows the point that re-seeding srand does not help in producing more random numbers. This is the best I can do since I don't have the PRNG.
I would note that rand echoes the exact same number when seeded with a new number. It's not only until the second time that it starts to differentiate.
I'm not sure it's possible to put any more evidence into this.
Use one. Don't re-initialize srand all the time. It wasn't designed to work that way and may not provide any results different from just getting that random number from PRNG.
daved said it above, but just to clarify, my argument was the calling rand() multiple times wouldn't be counter-productive, NOT that it improves randomness. the latter was just a shot in the dark, which I said so myself.
I also said that its precisely because we do not know how srand() is implemented, that we cannot say that it will improve OR worsen randomness.
lastly, the choice of seed is imo all important. in my experience, time(NULL) is only effective after a wait of 1000 ms, and even so produces linear results.
here's what I got my re-seeding srand() everytime with the output of the MT19937 prng:
as you can see, those results indicate a remarkably efficient randomness.
That is because you are NOT supposed to re-seed. You are supposed to do it ONCE and ONCE only, and from thereafter ONLY call rand and you will get your random numbers.
Then blame rand() and not srand(). srand() ONLY gives rand() an initial number to work with. I think I proved that to you before.and even so produces linear results.
If it produces linear results, it's because the rand() algorithm is not sophisticated enough for you in which case re-seeding multiple times will NOT help.
You should use a DIFFERENT random number generating library instead.
Oh so that's why we're being ignored, you're assuming we haven't seen the exact implementation of rand used by numerous compilers. Well it just so happens I am familiar with some of them.
Again, this is nonsense. Since you're never supposed to seed it between each random number then that coment is wrong.lastly, the choice of seed is imo all important. in my experience, time(NULL) is only effective after a wait of 1000 ms, and even so produces linear results.
You also said that by your interpretation of my post you didn't understand how you could cause it to repeat the last few results again. That's fine, just know that you're the one in the dark there, as some of us do know that you can cause this to occur. The things is though, that the way you're wrongly using it, even if you do make it start repeating part of the sequence, then you'll jump again to a different point before you repeat very much. That still doesn't make it better though!
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"