Mathestate Logo

 
DDiceAssume

Engineered Dice Assumptions and Requirements

Our data is a table of n integers that can only take the values of 2 through 12, inclusive, which arise from the following conditions. We have a pair of identical (to each other) six-face dice, each with pips of either 1,2,3,4,5 or 6 on a side. The "sides" of each die are identical trapeziods but the "ends" are, of course, squares of differing sizes. The taper variable determines the relative sizes of the "ends" as the cross section of the die tapers in a linear fashion along its original length. We assume in the deformation process that the volume of the die remains constant.

Each face has a probability, based solely on its relative surface area, that it will come to rest on the table, revealing the payoff on the opposite side. It is expected that the largest side will (naturally) come to rest on the table most of the time, therefore its probability is the highest. The numeric output is a list of probabilities in which the “pips showing up" payoff is in order of ascending payoff. That means that the smallest number of pips, 1, is on the large face of the dice, the one that is most likely to come to rest on the table. Thus, in that case it has the lowest probability and is represented by the first element in the list.

Remember that the sum of any two opposite sides of the dice is always seven. Thus, in the case of a .6 taper, the highest probability of 0.3075 is for the largest end. This is the face with one pip on it, which because of its size is most likely to come to rest on the table. This results in the payoff arising from the the opposite side, with six pips on it, coming to rest face up as most likely.

In order for the landing probabilities of such a die to depend solely on the relative area of its sides we must assume that the die is statically and dynamically balanced about its center. This means, roughly, that both the first and second moments of mass distribution are equal with respect to any axes through the center. Failing to require this introduces a nasty physics problem dealing with the other popular means of "loading" dice, adding weight to one side.

"DDiceAssume_1.gif"