And here's the flop. Those two spade's impossible inside straight draw really helped Genevieve with no help for Drew. Her odd wnet 32 percent to 55 percent. Drew has bet, Genevieve called. Here's the turn. The king of spades. Drew now has three kings, and Genevieve has a straight. Drew needs a king, jack, nine, or a red 10, giving him only a 21 percent chance here. Hit me. What was that for? The peanut butter and jelly video. And besides, this is poker, not blackjack. Are you betting or checking? I really wish I could see those probabilities that they put over there in the corner of the screen. Well, that would take all the fun out of the game, wouldn't it? Yeah, probably. But, hey, you know what would make a great project for our Coursera learners? It better not be teaching you to play poker. No, no, no. They could write a program that reads in a description of the poker hands, and does a Monte Carlo Simulation to determine the odds of each hand winning. Genevieve and I are playing poker. And you all can see the odds of each of us winning the hand, based on what cards we each have. How does this get calculated? When there is only one unknown card, you could pretty reasonably work it out by hand. But if there were many unknown cards, it could get complicated quickly. Wouldn't it be great to write a program that could figure this out for us? That's what you are going to do, with part of the project at the end of each course. To do this, we'll need to describe the hands in a way that is easy for the computer to work with. Here is the poker table from my perspective. In this variant of poker, which is called Texas Hold'Em, these seven cards are my hand. If you don't know how to play poker, that's okay. We'll explain the rules you need to implement this program. When all the cards are played, I'll pick the best five of my seven cards, and say what poker hand they make. At the moment, I have three kings. We can represent this in a way that is easy to work with by describing each card with two letters. One for the rank, and one for the suit. Here, I've described my two pocket cards, the ones that are just mine with Kh for the King of Hearts, and Kc for the king of clubs. I've described the known common cards similarly. The first three are called the flop, and the fourth one is called the turn. The fifth card which is called the river is unknown. So I've represented it with a question mark and a number. In this case, two. Everywhere that question mark two appears in this hand description, will be the same card which will be different from question mark zero and question mark one. Genevieve's hand is made up of these seven cards. Her two pocket cards, and the five common cards in the middle. Since I don't know what her pocket cards are, I represented them with question mark zero and one. She also has the same description of the flop and turn, since we share those, and also has question marks two for the river since we will share that card once it is dealt. You'll learn how to read input from files as well as how to dynamically allocate the memory to hold any number of hands that your program is working with in course four. Until then, we'll provide some compiled object files that will read the input for you. We can use this idea to describe other situations. Here are our hands before the flop is dealt. I know my two pocket cards, but no others. Question mark two through six represent the common cards which are as yet unknown, but will be the same in both hands. However, for the spectators and announcers, all the pocket cards are known. Having more information gives you a different calculation of the probabilities of the hands. Genevieve's hand is actually really good, so her odds of winning are better given what her hand actually is, than if we assume it is a random hand. Our input representation is flexible enough that we can represent many other common poker variations. For example, seven card stud has no shared cards, and some that are dealt face down, and some dealt face up. So that's how we'll describe the situation in a poker hand. But how will you actually go about calculating the odds? You could make your program consider every possible combination of cards. If you have four known cards and five unknown cards, as would be the case if we can see two players' hands, and have five cards yet to deal, you end up with about 205 million combinations. That's not so bad as computers go. We could do it in a matter of minutes, but we'd like to be faster than that. Could we work out the formulas for every case based on the principles of probability and combinatorics? Maybe, but that would be a lot of work especially given how many cases there are, and how much these depend on what other cards each other player has. Instead, what we are going to do is a Monte Carlo Simulation. So what is a Monte Carlo Simulation? You will draw a large number of random hands for the unknown cards, and see who wins, and count up how many times each of players wins the hand, and use those numbers as estimates for the probability of each player winning. If you do this for a large enough number of random draws, your answer will be very accurate. 100,000 random draws is pretty fast, and give estimates that are quite good. The idea of Monte Carlo Simulation is not just limited to poker or card games, but is a broadly applicable technique whenever determining the exact answer is incredibly complicated or computationally difficult. Let's head back to our poker game and see how it finishes. And here's the river, 10 of spades. Wow. Genevieve drew the straight flush. But Drew probably thinks his hand is good with a full house. All in. Call. Full house. Straight flush. And Genevieve wins the $25 million pot. What a game? Did I say a million? I meant 25.
