[CoLoCo] dice rolls in C

[Jim Hutchinson]

On Feb 6, 2008 7:36 AM, Kevin Fries <kfries at cctus.com> wrote:
> The problem with these types of "simulations" is that they rarely are
> able to properly simulate actual dice throws.  All they are able to do
> is pick pseudo-random numbers from an algorithm and normalize it between
> 1 and the number of sides on the dice.  This assumes in a perfect world,
> every number has an equal number of chances of coming up, and therefore
> should create a situation where every number will come up an even number
> of times, given a large enough sampling.

This is the point I'm going for. Dice rolling is actually one of the
true forms of random number generating. Computers are psuedo-random
and we want to "see" how that actually plays out. We want to see that
these these generators are not truly random. The reality, however is
that they are very good. I ran the C program with 10 million rolls and
10 billion rolls and the results just got closer to the theoretical
probabilities. I was going to run it 10 trillion times but it was
going to take more than 10 days. I was hoping to see periodicity and
maybe it's there. Maybe my test isn't sophisticated enough.

>
> The problem with this exercise is that it is neither random (has to do
> with how RPG works at the lowest level) nor accurate.  In a physical
> world, the dice throws are never truly random either.  Watch someone
> throw a pair of dice say 20 times.  Every time they will pick the dice
> up in a particular way, roll them in their hands in a particular way,
> and toss them in a particular way.  Each of these ways are as unique as
> the player.  Note the numbers that come up.  Then repeat the experiment
> with four other players.  Due to the differences in the way each person
> will do it, you will find, despite what you would think, certain numbers
> will come up more often for certain players.  This is one area where
> theory and reality are very different from one another.

This is a common misconception. While with a small sample you may see
certain number come up more often (you should see 7 more often because
it has the highest probability but with small samples that doesn't
always happen) the rolls are still random in that each roll is not
dependent upon any roll before - as long as you aren't just dropping
them from 2 inches with the numbers you want showing. Rolling a 7 on
one roll will not impact the odds of rolling a 7 or any other number
on the next roll. Each roll is independent. Given a large enough
sample this becomes obvious. 1000 rolls is not large enough and 20 or
30 is way too small. Using the true random number generator at
random.org I simulated 5000 dice rolls and the frequencies are exactly
what you would expect. If they would let you do 10 million it would no
doubt be even more perfect. 500 rolls wasn't bad either but you could
see the variability inherent in small samples.

> As a casino, having
> higher paying hands come up more often turns a winning machine into a
> losing one.

Casinos don't lose in the long run though because the odds are in
their favor. Given a large enough sample (like years and years of
playing) the casino always wins. Slot machines pay back around 97-98%
but if you continually lose 2% of your money you will eventually have
none left and the casino will have it all. It's called gambling
because you might get luck and hit a large payout. If you stop you
walk away a winner. If you keep playing you will give it all back.

Thanks again to all for the great discussion and information. I'm
still not sure how we are going to set this up as a true experiment
that a 6th grader can reasonably understand, do and explain.

-jim

-- 
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html