whether or not we agree that multiple srand calls with random seeds = bad is another question.
anway, PRNGs are for losers. QRBG is the way to go.
As an aside, it's usually good to print out, or otherwise log, the random seed being used. If you get a program crash which depends on random data, it will be difficult/impossible to reproduce unless you can generate the same random sequence as before. So it's good to know what the seed data was.
What does it really matter if you can predict the next random number, so long as you are getting a good distribution? Computers are deterministic, and short of using something like the QRBG, which is pulling "random" info from a source outside of the computer, you will never get "truly random" numbers from any algorithm.Quote:
Originally Posted by shawnt
This slowdown may not be noticeable in the instance of a simple dice rolling simulator for a mere 10,000 iterations, but crank that up to a million iterations (or to magnify it so it is even clearer, a billion iterations) and see what kind of time difference you get between MT.out used raw, and srand(MT.out); rand();. Then compare that difference to the statistical analysis of all of those dice rolls with each method.
You might think that seems absurd. However,
Wouldn't it be really great if your program allowed you to switch between different PRNG's by doing something as simple as changing a compile switch? You could then see for yourself whether rand gave results that were indistinguishable from those of something better.Quote:
Originally Posted by shawnt
I am working on a personal project which requires me to generate large amounts of truly random numbers (hint: its about probabilities).
You could even be able to select from various PRNGs at compile time. Another one you could use is CryptGenRandom (on Windows).
Surely it's a win-win. You either prove that your compiler's rand is crap, or you can discover that it is not only good enough, but is likely faster too.
I think we have already put to rest the question as to whether rand coupling adds any value or not. It doesn't.
I believe we have also established that multiple resetting of a prng by re-seeding with a random seed is not detrimental to the randomness of a distribution. Its simply a redundant code ovehead.
Moving on, I will be comparing QRBG's results with Mersenne's (if I can ever get QRBG to work :rolleyes: ). I am not interested in the program's efficiency with one implementation vs the other. The main purpose of this project was to use the program as a tool to study the manifestation of probabilities.
So far, I've had to limit my simulation to 10,000 iterations because past that, the results screw up. I'm not sure why this is the case, since all my integer constants are defined as long int. Any ideas?
Lastly, on a physical note, I am now inclined to believe that the only guage there can be for true randomness is close adherence to the theortical probabilities of known events. So a randomness source is close to being 'truly random' if it delivers each element of a binary distribution approximately 50% of the time, spread out over a distribution much greater period. That would encompass both even distribution and unpredictability. This is where probabilistic manifestation starts to feel mystical (what ensures that a coin will flip heads 50% of the time?). Of course its no more mystical than the force of gravity, but theres a certain allure to it which is what drew me to this project.
>So far, I've had to limit my simulation to 10,000 iterations because past that, the results screw up.
I bet if you do:
this won't happen.Code:
final_out = MT.out;
> anyone have any ideas why?
Assuming you're expecting more, then the answer will be a bug in your code.
If you can post a short example which demonstrates the problem (like cut out anything which isn't called yet, and any non-critical screen I/O say), then we could probably tell you where you're going wrong.
Look for uninitialised pointers, arrays being overrun etc.
You'll need to allocate arrays that large dynamically (recommended to use std::vector to do that for you). Stack space for automatic variables and arrays is only about 1 MB.)
You'd be surprised how common that usage is.