Yeah, I should have anticipated that one. The reason is because with less convoluted code such as yours I am finding the same number comes twice on ten attempts with suspicious frequency.

1) Is there something about placing the code in the main loop that makes it any more random?

2) I guess what I am asking is whether by making the code absurdly convoluted I am also making it absurdly inefficient or whether on modern hardware this code could be called every second or two with a neglible performance hit.

1) No? Why would it? The code will run the same no matter where you put it. Computers would be a lot more frustrating otherwise.

2) When you have billions of instructions running per second, you can do pretty much whatever you want once or twice a second with a negligible performance hit.

Lastly, unless you really think that you know of a neat new way to create random numbers, just stick to the beaten path. The C random() function works quite well. Some people also swear by ranrot (Google for it).

No matter how you cut it, random number generators on computers are *pseudo* random number generators. That is, they aren't truly random. You'll find a pattern no matter what. True randomness requires chaos, and computers just don't do that without special hardware. One thing I've always wondered is why they (engineers) don't make use of the fact that semiconductor junctions are noisy. All they gotta do is put one single noisy transistor on the board and read it with an A/D converter, but whatever, maybe there's a reason why they don't...

Woah, no kidding! I didn't know that. That noise is *exactly* the same junction noise I'm talking about.

FWIW, I started my programming days back then, but I had a CoCo 1 (you know, the big clunky silver one). I don't recall there being any access to the audio generator, but memory is pretty hazy going that far back...

Just make sure you call srandom() exactly once in your program. The more often you call it, the less random your numbers.

And if random() isn't random enough for you, you can always grab an implementation of the Mersenne Twister from the internet, or just read /dev/urandom. Personally, I've always just used (double)rand() / (double)RAND_MAX, or (rand() >> 16) % n, and never had a problem.

That and a lot of intro to statistics courses dispel common misconceptions about probability... For example, if you roll two sixes on a six sided die... what's the probability of getting another six? Yeah... one in six.

That and a lot of intro to statistics courses dispel common misconceptions about probability... For example, if you roll two sixes on a six sided die... what's the probability of getting another six? Yeah... one in six.

I'm pretty sure it's 0.46% (if they are not mutually exclusive) or rather, .46% chance to get 3 6s in a row.

AndyKorth Wrote:But the chance to roll a six given that you've already rolled two sixes is 1 in 6.

Totally OT:

It depends on who's rolling the dice and how desperate the situation is. I've seen guys roll six sixes all at once in Axis and Allies, pretty much at will, when they needed to roll damage or technology.

I know, I know, I kid... But anyone who's really done a lot of table gaming can tell you they've met some rollers who have clearly bent what probability would have predicted. My buddy John can roll a one in a thousand if the situation is dire enough...

Quick story: One time we were sitting in the living room and my friend John bet me five bucks in front of a bunch of visitors that he could throw his bottle cap over his shoulder without looking and get it in the garbage, twenty feet away. The garbage was well overflowing and so everybody was saying to do it (not to mention it was an impossible throw behind the back). I said no way, and everyone was shocked and laughing at me because I turned the bet down, so some other fool did it. I told them I never bet against John on luck. Well, he did it and they lost the bet, mouths dropped and all.