I'll outline the conceptual steps involved in the computation then discuss some
implementation strategies. To keep things simple, I'll start ignoring ruin.
I recall writing about this before-- but whatever...
Conceptually you start with the PDF for the "game" or the PDF for 1-hand of the game.
You then compute the PDF for N-hands of the game and then add up (integrate it) to get
the CDF. To be fair, this PDF is really just a table consisting of all the possible outcomes
from the game and their probabilities of occurring.
So-- where do you get the PDF for the game?
It's precisely the payout table with a 0 added in for Nada (don't forget the zero) and the
final hand probabilities. Where to get the payout table is obvious. The final hand
probabilities (for each payout, including zero) come from your favorite VP simulator or you
find them on the web, etc.
This PDF looks like to columns of numbers,
0, 0.60
2, 0.13
and so on
The first column here is the payout, the second is the probability. I prefer to use fractional
units rather than percentage though here. The second column, the probability, must sum
to exactly 1. if it doesn't your cdf with be wrong.
The procedure of turning a PDF into a CDF is relatively straight forward. First, you sort the
table in increasing order of the payout (smallest first). If it is sorted, skip this step.
Second, you replace rows in the same that have the same payout (this can happen) with a
single row that has a probability equal to the sum of the rows you are removing. Third,
you create a new column in the table that is the running sum of all the probabilities. This
third column has units of probability. Its first values should be the value for nada and its
last value should be 1 (or 100) or something is wrong already. The first and the third
(new) column comprise the CDF-- computed here as the integral (sum) of the PDF. If you
plot the CDF, you probably want to have a horizontal payout axis (x) and a vertical
probability axis (y)
So that's how you get the CDF for 1-hand of any VP game. To get the CDF for 2 hands,
you need the PDF for 2 hands and then apply the same procedure on it as described
above. For 3 hands you need the pdf for 3 hands, and so on.
But where to you get the PDF for 2 hands? This is where the fun begins. Conceptually,
you need to figure out all the possible outcomes (and their probabilities) after two hands
of play (ignore ruin for now). Let's see, you could have lost the first hand, and lost the
second; lost the first, and got a high pair, lost the first, got 2 pair,... etc, all the way to
getting 2 RF's... (yes it could happen, so you need to include it). You all need to get the
probabilities of all this things occurring. To do that you take the probability of the first
event and multiply it by the probability of the second event occurring. You already have a
table of these probabilities-- its the PDF for the game (don't forget nada!)-- all you have
to do is create the new, much bigger table with everything multiplied by everything else.
Then clean it up (sort it and combine duplicate rows)-- and you have a nice 2-hand PDF--
one step away from the CDF (which just needs the running sum column)
I suspect you can see that finding the CDF (or PDF) for n- hands, where n is large, would
be a pain following this procedure. So don't try to do it this for more than for hands
maybe 10 if you are using a spreadsheet. Instead you are going use standard techniques
to compute these kinds of things much more quickly.
BTW, what you did is compute the convolution of the 1-hand PDF with itself. It turns out,
the n-hand PDF can always be computed by convolving the 1-hand PDFs with itself n-
times... but its a pain, as you know, to compute convolutions by hand.
It turns out, that, if we can ignore ruin, there is mathematical trick that allows us to quickly
compute the n-hand PDF. Explain why this works is beyond the scope of this post, but
trust me, it works fine:
PDF (n-hands) = Inverse Fourier Transform{ [Fourier Transform ( PDF 1-hand)] ^ n}
(ok, don't trust me; here's the first proof that popped up for me on google http://www-
structmed.cimr.cam.ac.uk/Course/Convolution/convolution.html#conv_theorem)
[now it gets really ugly...]
To be complete, I'll discuss one possible implementation, using excel, though, I don't
really expect this comments to be complete enough for you to easily follow them. Excel,
BTW, has a fourier transform function. That's the good news. Other than that, its a pain
to use, and It's not always load be default-- so you may have to search around you
installation to find it. Excel is not the right tool here, though it can be coaxed to work and
you can use it to compute the n-hand PDFs, etc. But you will have to be very careful. You
are going to have to do the FFT's (fast fourier transforms) on a very BIG table of all the
possible outcomes (& probabilities) for the n-hands. This table should include a long list
of possible total payouts, starting with the biggest loss possible (make it VERY big, as in
you actually lost each hand) running up to at least a couple of royal flushes. The list of
payouts a must be equally spaced with no missing values (as in 1,2,3,4 NOT 1,4,5), so
most of the probability entries in it the table will be zero!. [Note: the length of your table
should either be a power of two, like (2, 4, 8,...1024,2048,4096, etc) or a product of
primes -- or maybe it doesn't matter for excel. I don't have it in front of me, you should
check on this to get the best performance]. You then take the FFT on this big table
(acutally just on the probability column), take the n'th power of the result (you have to do
this on a complex number!) and then transform back. In my old version of excell, I had to
start with complex numbers so that means one more column in your table (full of zeros).
Maybe some excel guru out there can help you with this.... I'm also sure I've made a lot of
typos and errors here sorry...
···
--- In vpFREE@yahoogroups.com, "deuceswild1000" <deuceswild1000@...> wrote:
I would love to compute CDFs for the games I play. How do I do that?