[CoLoCo] dice rolls in C

[Neal McBurnett]

This article has some great insights on randomness and dice and coins
- spinning coins vs flipping them, biasing dice by rounding corners or
making the side lengths different, etc.

Great insights to design real experiments that everyone will "get".

 You can load a die but you can't bias a coin
  Andrew Gelman and Deborah Nolan April 26, 2002 

 http://citeseer.ist.psu.edu/605305.html

 http://citeseer.ist.psu.edu/rd/83657428%2C605305%2C1%2C0.25%2CDownload/http%3AqSqqSqwww.stat.columbia.eduqSq%7EgelmanqSqteachingqSqpublishedqSqdiceRev2.ps

-Neal

On Wed, Feb 06, 2008 at 07:36:19AM -0700, Kevin Fries wrote:
> 
> On Tue, 2008-02-05 at 16:58 -0500, TheZorch wrote:
> > Andrew wrote: 
> > Here's a challenge.  Create a program which can do RPG dice rolls.
> > RPG dice are your average 6 sided (should be able to specify now how
> > many) plus a 20 sided, an 8 sided, two 10 sided for percentages, and a
> > 12 sided die.   I can't remember anything I learned of C back in 1995.
> > I was programming on Unix at the time and it was ANSI-C not C/C++.
> 
> 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.
> 
> 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.
> 
> Casinos had the same problems with the introduction of card based
> gambling machines.  The standard way of "shuffling" a deck was to assume
> that if the desk was truly shuffled, each card would have an equal
> chance of coming up at any point.  So the standard method was to have an
> array of 52 cards and an empty array.  Pick a RPN from 1 to 52 and
> remove that card from array 1 and add it to the end of array 2.  What
> the casinos found was that the odds of hands actually changed!  Think
> about how cards are actually shuffled.  The deck is cut approximately in
> half (within 5 to 7 cards of half would be a good estimate) then cards
> are transferred from the BOTTOM of each stack 1, 2, 3, maybe even 4 or 5
> at a time before the same is done from the other stack.  This causes
> cards of the same suit (assuming you are starting from an unshuffled
> deck).  This increases the chances of flushes and flush straights
> because cards starting from similar places have a better chance of
> staying together, than with the truly RPN method.  As a casino, having
> higher paying hands come up more often turns a winning machine into a
> losing one.
> 
> The same problem occurs with dice.
> 
> The real trick is how to create a roll mechanism that really does
> emulate how people roll dice.  Then apply that physics engine to the
> roll of the dice.
> 
> Just a thought
> 
> -- 
> Kevin Fries
> Senior Linux Engineer
> Computer and Communications Technology, Inc
> A Division of Japan Communications Inc.
> 
> -- 
> Ubuntu-us-co mailing list
> Ubuntu-us-co at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-us-co