# Calculating Odds

**Posted:**December 30, 2015

**Filed under:**Uncategorized Leave a comment

I came across an interesting dice game called “Cubes” (which is essentially a simple version of craps) recently and decided to calculate the odds. This post will be interesting if you have some background in Probability and Calculus. It will be even more interesting if you don’t and are curious to know what these maths can do.

## The Game

A player of Cubes places a bet and two six-sided die are rolled. If the sum of the die is 7 or 11 the player wins twice the pot. If the sum of the die is 2, 3, or 12 the player loses the pot. Otherwise the number rolled becomes the player’s “point” and the player makes another bet (which goes into the pot with the first bet) and rolls again. If the player rolls his point he gets twice the pot, if he rolls a 7 he loses. The player keeps betting and rolling until he either loses or wins.

The game is interesting because it’s not immediately obvious how the odds work out. Consider the first roll. The player can win with a 7 or 11 which have probabilities:

and lose with a 2, 3, or 12 which have probabilities:

Below is a simple probability table for reference.

Anyway it would appear upon first inspection that your odds of winning are twice as good as your odds of loosing. Very good. But what about when the player rolls something other than a 7, 11, 2, 3, or 12 and it becomes his “point”? In this case the player has a higher probability of rolling a 7 (note this is the most frequent number in the table above) than any of the possible “points” he could have rolled. At this point the game is a loosing battle. However the player started with much better odds of winning outright. So which of these competing forces wins out?

To figure this out we’ll use some basic Probability and Calculus. We wish to determine the probability of winning a game of cubes. To do this we need to sum up the probability of every way in which we can win. If you’re not familiar with the axioms of probability consider a simple example:

## Warning: Balls in Urn Example

Imagine you have an urn with red ball, a blue ball, and a black ball of equal size, shape, etc.. You win a prize (penguin) if you draw any two balls from the urn and one is red without looking into the urn. What are the possible combinations?

red blue | red black | blue black

Three different combinations, each equally likely. Two of these will win us a penguin. To determine the chance of winning we simply sum the probability (1/3) of each of the combinations that allows us to win. This gives us 2/3 which makes good sense given two of the three options will win use the penguin

Back to the game of Cubes. Now just as in the urn example we must sum up each of the possible ways (or events) in which we can win the game. We already know one event that will lead us to win: rolling a 7 or 11 during the first round (with a 2/9 probability). Now we just need to figure out the remaining ways we can win and add them up.

The only other way we can win is by rolling our “point” before a seven. To get to a point round in the first place we must not have one outright and not have lost out right. Let’s consider the event where we get to the point round by rolling a 5 and win:

Here we have the probability of getting to the first point round multiplied by the probability of rolling a 5. This event constitutes a win, so we’ll add to to our sum. Let’s generalize a bit and call the probability of rolling our point (in this case 5) q. We’ll also expand the idea such that we capture the case where we roll our point after one failure, two failures, etc.:

Where the new term in brackets is the probability of not rolling your point or a 7 (which allows the player to move to the next round). Note this term’s exponent increases by one each turn as the player must continue to not roll his point or a 7. This series is infinite as it’s possible for the rolling to go on forever. Let’s make it look nicer:

This is a geometric series with a closed form solution. I’ll leave the proof of the closed for solution and the algebra to the reader. We end up with a very clean result:

We’re almost done. We’ve accounted for an infinite number of rolls events that lead up to a win but for only a single value of q. We need to adjust this solution slightly such that it accounts for the different possible point values a player could roll and their corresponding probabilities. It turns out we only need to worry about three values of q since 4, 5, 6 and 10, 9, 8 have the same respective probabilities. We multiply each of these possible values of q with the probability that we rolled that point value. For example a player could roll a 4 or a 10 with a probability of 6/36 = 1/6 which would give us a q value of 3/36.

This give us 0.4929292…. It’s actually quite remarkable this game is so close to fair. In any case over a large number of trials we expect to loose. Not a good bet, but a great analysis.

# Irreverent opinions of languages in which I have coded.

**Posted:**November 22, 2015

**Filed under:**Uncategorized Leave a comment

This list served as an interlude to a presentation I gave recently.

- SQL – Most boring / useful
- PL/pgSQL – wtf is this? I have to write database functions in this?
- Bash – Useful and fast. Nobody knows how to write in this.
- C – God. Dangerous. Caused heartbleed bug. Bad language! ::Language runs off::
- Matlab – haha
- Perl – Madness. Fast.
- Ruby – For hipsters / designers. Slow but sexy.
- Mathematica – Designed to clash with every other language’s syntax
- Java – enterpriseCodeThatMakesYouWishYouWereDead (deprecated)
- Javascript – Great if used properly. Not used properly.
- PHP – [censored]
- Julia – Smart, Sexy, Fast. Innate parallelism.
- Scala – So many features / idioms it pretty much guarantees a month of 12 hour days before you can read more than 50 lines in a row.
- R – Makes $. Errors and warnings written by devious children.