Listen up you little dice monkies

[Lamoni]

(Now, if you want to really open a can of worms, try to convince a gamer that human beings cannot tell the difference between random/nonrandom number streams in a six-sided die rolled six times...)

I would also like an elaboration. By human beings, do you mean ALL human beings? And by random/non-random do you mean high probability of randomness vs. low probability of randomness? A sequence of 6 1's could still be random, but the probability of it being a random outcome is quite low.

 

[orsal]

I would also like an elaboration. By human beings, do you mean ALL human beings? And by random/non-random do you mean high probability of randomness vs. low probability of randomness? A sequence of 6 1's could still be random, but the probability of it being a random outcome is quite low.

Here's an exercise I occasionally give my intro prob/stats students: I give them three sequences of H's and T's, all the same length (at least 60 tosses), and ask them which of the three was a simulated coin toss. In acutality, one of them is a simulated toss of a fair coin (independent probabilities, 0.5 for each), one is a simulated toss of a weighted coin (independent, but tails significantly more likely than heads), and the third is cooked so that heads will more often be followed by tails, and vice versa. (I'll suppose they're given in that order, although I actually change the order from time to time.)

The first thing nearly everyone looks for is the total number of heads and tails. They (correctly) expect close to half of each, and on that basis rule out sequence #2. It's harder to choose between #1 and #3, but the most common criterion used is long homogeneous strings. A lot of students will look at #1 and decide that there's a string of consecutive H's or consecutive T's that's suspiciously long. #3, of course, is cooked up to avoid long homogeneous strings, and to most people that "feels" more random. It's a surprise to learn that randomness generally does produce patterns of all kinds writ small. Toss a coin enough times, and you will at some point get 289 consecutive heads. A string of 7 consecutive H's or 7 consecutive T's happens one time in 64; if you toss 70 coins, there are 64 strings of 7 consecutive tosses, and on average one of them will be homogeneous. It's more complicated to calculate the actual probability of getting at least one homogeneous string, but it's better than even.

So the very feature that should suggest that #3 is not truly random, is what leads most people to guess it is. The situation would get even worse if I asked you to write down a pseudo-random string of H's and T's off the top of your head. (Well, maybe not if I asked you. Maybe you're weird. But if I asked almost anybody.) I'd likely never see more than three consecutive H's or T's. People's attempts to imitate randomness invariably err by producing too much alternation.

Likewise, if you tossed a d6 100 times, chances are you'd get 2-3 homogeneous runs of 3 (of anything), since the probability that a particular run of three tosses will be homogeneous is 1/36, there are 98 runs of three, and 98/36=2.7 But if I asked someone (who hasn't read this post or anything similar) to write down 100 numbers from 1-6 "as if they came from a die", I'd bet I'd not see a single 3-in-a-row.

Note that if you roll a fair d6 100 times, any *specific* result is as likely as any other. But there are some *patterns* that suggest non-randomness, and studiously avoiding patterns such as homogeneous streaks leads to a different kind of pattern which is just as improbable.

 

[Kyrail]

The easiest way is to get a dice rolling program (assuming computer nearby). Of course, that's assuming you trust pseudo-random algorithms. Being a programmer, I don't.

Ya know I always wondered how computers could *ever* be random. I mean, they're a set of paramiters that they follow exactally, how do you get random out of that? :\

 

[DemonAtheist]

just use a TI-83+, randInt 1, 13

oooh...ti's are also good for mass rolling, like fireball or sneak attack, since you can use the sum command (sum randInt 1, 6, x)

 

[Hypersmurf]

I mean, they're a set of paramiters that they follow exactally, how do you get random out of that? :\

You don't. But you can get randomish.

What time is it? (Answer to the nearest microsecond, please.)

-Hyp.

 

[Vrecknidj]

Roll 1d6, if it's odd, add 7 to the next roll, if it's even, add 0 to the next roll. On your next roll, roll 1d6.

Dave

 

[Hypersmurf]

Roll 1d6, if it's odd, add 7 to the next roll, if it's even, add 0 to the next roll. On your next roll, roll 1d6.

What's the chance of rolling a 7 on your proposed 1d13?

-Hyp.

 

[The Souljourner]

Yeah... it's about time.

What Hyp is talking about is that time on computers is denoted by a long-ass number - the number of microseconds since Midnight, January 1st, 1970. So what you get is something like 1,073,741,824,476,728. (that's 1:37pm on January 10th, 2004, in case you couldn't tell). The last six digits of this are pretty random... the exact 1 millionth of a second at which you ask what time it is, is pretty random. So, what computers do is use these last few numbers in the time to determine what number comes out of the "random" number generator. You can then use that number to do whatever you like, like using it to determine a number from 1-13.

-The Souljourner

 

[Fieari]

Well, actually, computers tend to use the time (in ms) in order to SEED a random number formula, not to generate the actual number. Interestingly enough, human beings are surprisingly good at timing even at that level, and when keyed to the clock like that there are people who can intuitivly use it to their advantage. Besides, with certain loops, each time the funciton would get called might occur on the same or a very VERY predictable pattern of numbers.

The actual method of "random" number generation varies from language to language, but I'm pretty sure that the C/C++ rand() function is basically the following line:

return next = (unsigned int)(((next * 1103515245 + 12345) / 65536) % 32768);

With next being set by srand(unsigned int), and is usually made the current time at the start of the program. After the program is loaded into memory, the rand function no longer cares about time and does its own thing. An interesting facet of this particular formula is that it wraps around.. that is to say, that when the multiplication of the previous "next" with 1103515245 gets to be too big, it wraps around to start at zero again, making a very interesting spread of numbers that doesn't repeat for a considerable period of time, by which time you likely won't notice anyways. All pseudo-random numbers will repeat EVENTUALLY, but better ones take longer to do it.

 

[The Souljourner]

Yeah, that's what I meant when I said it "determines what number comes out of the random number generator".

Seeding and generating are the same thing. To seed is to fill in a value of the equation, which is used in generating the random number. In your equation, the value next is the seed (the current time in milliseconds). That value is then used to generate the actual number.

If you give the same seed, you'll get the same answer. That's deterministic.

-The Souljourner