Thread: random isn't really random?

Originally Posted by shawnt

by invalidated, i meant that srand(MT.out) output is much more random than srand/rand alone.

As stated earlier, by your definition of "more random" (i.e. harder to predict), yes because then even if one knows the algorithm, it is more obfuscated and takes longer to figure out. However this is something that you have stated is not really an issue:

Originally Posted by shawnt

i also fully agree with your analysis of the vulnerability of PRNGs or combinations thereof as applied to cryptology. since my application utilizes PRNGs for statistical simulation, the impenetrability of the PRNG algorithm is irrelevant for me.

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.

Originally Posted by shawnt

you said that coupling the two would "at best" give the results of the poor prng. i found this to not be the case since the results I got via coupling were FAR more random that srand/rand alone.

You would most definitely find that using the Mersenne Twister in the manner you have to be FAR more "random" because srand/rand by itself is a poor prng. I mean no disrespect, but do you know what a Ceasar Cipher is? If not, please look it up because that is essentially what you are doing to the result of MT. srand()/rand() always "shifts" the MT.out in exactly the same way, so of course it looks more random; you are getting the "more randomness" of the Mersenne Twister and then just "adding 20 to each result" (WAY oversimplification, but hopefully you get my point).

Originally Posted by shawnt

anyway, it doesn't matter. since I am now believe that coupling prngs does not improve randomness, I will not use rand for my program...even though I didn't see any harmful effects either by coupling or by making multiple calls to srand().

A harmful effect (on the basis that srand()/rand() doesn't actually do anything except camouflage the result of MT) is that is slows your program down for no appreciable gain. Unless of course you feel the need to obfuscate the process.

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,

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).

Why slow your program down? In the world of optimization, this would be considered a pessimization. You are using a slower algorithm in place of one that does the exact same job with much better efficiency (i.e. not calling code that merely shifts the result), for no gain.

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).

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.
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.

Originally Posted by iMalc

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.
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.

Good suggestion. One step further would be a runtime option - using a (set of) function pointer(s) to hide the actual RNG. Then you can give for example a command-line switch or a radio-button selection box to choose which to use. You could then also automate the testing and find out in the end of a long run what all the results are.

--
Mats

Originally Posted by Ducky

I changed your program with srand() but i get
"void value not ignored as it ought to be" error.

Code:

int flip(void)
{  
    int outcome;
    outcome = rand () % 2;
    return outcome;
}

int main () {
  srand ( time(0));
  /* The rest of your program */
}

I tried to google it without success.
Anyone please?

srand doesn't generate random numbers. It seeds the random number generator. Call it at the beginning of your program before you call your rands.

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 ). 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:

Code:

final_out = MT.out;

this won't happen.

> 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.)

Originally Posted by shawnt

anway, PRNGs are for losers. QRBG is the way to go.

In reality, PRNGs are far more useful. For example in a saved game file such as Warcraft3 it would simply store the random number seed used for the game and then the whole game can be played back later with the exact same random decisions made the whole way through. No need to store every random number result in the file.
You'd be surprised how common that usage is.