Getting randomized

[Zeb_Carter]

Depends. Pseudorandom methods aren't random but for this purpose someone would have had to have screwed up badly for the results not to be plenty good (meaning plenty fair) enough. If they really wanted it to be truly random, there are options (including random.org, which is truly random if you believe randomness exists at all.) But there'd be no reason to bother.

True random is throwing a fist full of dime in the air all at once and counting how many came up heads and how many hit you in the head. That's why you use dimes instead of silver dollars.

Other than that, no matter how many random number generators you have in a computer, the results after a few cycles is predictable. The same number will come up more and more, until the generator is reseeded. Then the cycle starts all over using a different starting set.

In discussions on a SQL board the RAND() function always returns the same dataset and it is suggested that you use NEWID() function to return a random sample dataset from a database table.

 

[Bramblethorn]

True random is throwing a fist full of dime in the air all at once and counting how many came up heads and how many hit you in the head. That's why you use dimes instead of silver dollars.

Other than that, no matter how many random number generators you have in a computer, the results after a few cycles is predictable. The same number will come up more and more, until the generator is reseeded. Then the cycle starts all over using a different starting set.

In discussions on a SQL board the RAND() function always returns the same dataset and it is suggested that you use NEWID() function to return a random sample dataset from a database table.

If your PRNG is cycling after only a few calls, then either it's very badly designed or it's not being used correctly.

A decent PRNG will have an extremely long period; for instance, the Mersenne-Twister implementation I use at work will generate 2^19937-1 numbers before repeating the sequence. That's about 10^6001 numbers; generating a trillion random numbers a second, you won't see the sequence repeat in the lifetime of this universe.

Where people often go unstuck with PRNGs is choice of seed (i.e. where in that sequence to start). SQL's RAND() requires a "seed" argument that tells it where in that sequence to start. If you don't supply that argument and just call RAND() it will use the same default seed every time, hence you get the same output.

This behaviour isn't universal - e.g. some PRNG implementations will default to a method that selects a hopefully-unique seed and then return a stream based on that seed.

Non-randomness of PRNGs can be an issue for crypto and some high-powered mathematical work, but for anything else a halfway-decent PRNG is as random as makes no difference, when properly implemented. Certainly for the purpose we're discussing here.

 

[Zeb_Carter]

If your PRNG is cycling after only a few calls, then either it's very badly designed or it's not being used correctly.

A decent PRNG will have an extremely long period; for instance, the Mersenne-Twister implementation I use at work will generate 2^19937-1 numbers before repeating the sequence. That's about 10^6001 numbers; generating a trillion random numbers a second, you won't see the sequence repeat in the lifetime of this universe.

Where people often go unstuck with PRNGs is choice of seed (i.e. where in that sequence to start). SQL's RAND() requires a "seed" argument that tells it where in that sequence to start. If you don't supply that argument and just call RAND() it will use the same default seed every time, hence you get the same output.

This behaviour isn't universal - e.g. some PRNG implementations will default to a method that selects a hopefully-unique seed and then return a stream based on that seed.

Non-randomness of PRNGs can be an issue for crypto and some high-powered mathematical work, but for anything else a halfway-decent PRNG is as random as makes no difference, when properly implemented. Certainly for the purpose we're discussing here.

That's what I said. Only I didn't fancy it up with all the big words or the meaningless number references.

 

[Bramblethorn]

That's what I said.

Perhaps that's what you meant to say, but what you said was:

"...no matter how many random number generators you have in a computer, the results after a few cycles is predictable. The same number will come up more and more, until the generator is reseeded"

Those statements are simply untrue for something like the MT19937 PRNG I mentioned. Just seed it once, and it will give you a stream of numbers that won't cycle within the lifetime of the universe. You'll never need to reseed it, and far from "the same number will come up more and more", the results will be more evenly distributed than any physical coin-toss, because no coin is perfectly 50/50.

Is it predictable? Yes, if you're a crypto expert and you get to observe at least 19968 bits of output in sequence... but neither of us are crypto experts. I wouldn't use that particular PRNG for encryption (there are better options designed for that purpose) but for the original context of this discussion, it's as random as makes no difference.

Only I didn't fancy it up with all the big words or the meaningless number references.

If words like "Mersenne" or "implementations" seem exotic to you, or if you don't know how to read exponential numbers, perhaps that just might be a clue that your knowledge on this topic isn't as robust as you're making out.

Yep, people often misuse PRNGs and write crappy code that delivers obviously non-random output. But that's a matter of user error, not an inherent limitation of PRN generation.

 

[Zeb_Carter]

Perhaps that's what you meant to say, but what you said was:

"...no matter how many random number generators you have in a computer, the results after a few cycles is predictable. The same number will come up more and more, until the generator is reseeded"

Those statements are simply untrue for something like the MT19937 PRNG I mentioned. Just seed it once, and it will give you a stream of numbers that won't cycle within the lifetime of the universe. You'll never need to reseed it, and far from "the same number will come up more and more", the results will be more evenly distributed than any physical coin-toss, because no coin is perfectly 50/50.

Is it predictable? Yes, if you're a crypto expert and you get to observe at least 19968 bits of output in sequence... but neither of us are crypto experts. I wouldn't use that particular PRNG for encryption (there are better options designed for that purpose) but for the original context of this discussion, it's as random as makes no difference.



If words like "Mersenne" or "implementations" seem exotic to you, or if you don't know how to read exponential numbers, perhaps that just might be a clue that your knowledge on this topic isn't as robust as you're making out.

Yep, people often misuse PRNGs and write crappy code that delivers obviously non-random output. But that's a matter of user error, not an inherent limitation of PRN generation.

And the end it near too.