![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
In idle moments I often contemplate the creation of a general theory of heads up betting in poker-type games, one which would be immune to the comment "ah, but in real life...", because you could respond with the line "anything which occurs in real life is incorporated in the numbers".
The development of the theory would start from a situation postulated by Sklansky where, with all five cards on board, you have to decide whether or not to bet. It would ignore actual numbers (those are inputted by the user) but would not require any general assessments. Everything, as it were, could be reduced to percentages.
A simple start would follow this line:
a) What is the chance if I bet that I will be called and I will lose?
b) What is the chance if I bet that I will be called and win?
c) What is the chance if I check that opponent will check and I will win?
d) What is the chance if I check that opponent will check and I will lose?
e) what is the chance if I check that opponent will bet, I will call, and I will win?
f) What is the chance if I check that opponent will bet, I will call, and I will lose?
g) What is the chance if I bet that opponent will fold and I will win?
h) What is the chance if I bet that opponent will raise, I will call, and I will lose?
i) What is the chance if I bet that opponent will raise, I will call, and I will win?
j) What is the chance if I bet that opponent will raise, I will fold, and opponent will win?
That roughly covers all situations bar re-raises, which I have excluded for the sake of brevity. Since they cover all situations, they must add up to 100%.
We can simplify this by creating two scenarios, one in which I bet, and one in which I check.
These individual scenarios also both add up to 100% (200% in total) because they alter the starting point. In one, the fact that I am betting is a given, while in the other, the fact that I am checking is a given.
Now, to this we need to add two other important pieces of information, those being the size of my bet and the size of the pot.
In this sense, limit poker is merely a "special case" (subset) of no limit poker. One in which the size of your bet is restricted to two levels, zero (= check) and a positive sum (= bet)
Now, I would contend that, once you have delineated the size of the pot, the size of your bet, and the various probabilities outlined above, then you can obtain an expected value from any size of bet. The actual cards here don't matter (in fact, the nature of the game itself doesn't matter); all that matters are the probabilities of being called and winning, being called and losing, and so on.
This doesn't eliminate the skill involved -- assigning these probabilities is one of the great arts of poker, and great players "do the right thing" through experience and through skill at assessing how likely they are to be good (and be called).
One can start at extremes. Let's take a situation where you have the nuts, and the situation where you have the worst hand possible. You are also up against two types of player, one who never folds (but never bets), and one who always folds (but never bets).
In case (a), you have the nuts against the always caller. There is $100 in the pot and its $10-$20.
Your EV if you bet is $120
Your EV if you check is $100
In case (b), you are up against the always folder.
Your EV if you bet is $100
Your EV if you check is $100
In case (c) you have a certain loser against the always caller
Your EV if you bet is minus $20
Your EV if you check is $0
In case (d) you are up against the always folder
Your EV if you bet is $100
Your EV if you check is $0.
Now, the interesting thing about these scenarios is that, if we ignore raises (for the moment), we have covered all the bases. Your hand is always somewhere between the nuts and a certain loser, and your opponent is always somehwere between a certain caller and a certain folder. If you assign percentages to these, you enter the land of "getting folds when you are losing, and getting calls when you are ahead" -- those things which give the value bettor the edge at the end.
Suppose, for example, you have no idea about your opponent. You cannot assign any probability (this is extreme, because you always have something to go on, even if it's a "default player" attribute). In that case, you have the principle of "in the beginning, everything is even money". You assume there is a half-chance that opponent will call.
Once again, you always bet the nuts (EV is now $10), and, with the certain loser, you also bet, because half the time a bet wins you $100, while half the time you lose just $20, giving a total positive EV of $40.
But, well, in real life, you will often have numbers that are far messier, say, a 35% chance of being ahead and a 72% chance of being called. The more accurate your assessment of your chances of winning/losing, and the more accurate your assessment of the chances of opponent calling/folding, the more money you will make with river bets.
As you can see, just a simple application of the possibilities quickly gets complicated, but that doesn't make it impossible to program, just rather difficult.
But this is just the river. What about turn, flop and pre-flop? What about No Limit or pot limit?
Here something written by Chen came like something of a revelation. A call or fold on the river brings about an immediate outcome. The value of that call or fold is immediately revealed.
However, a bet, call (or fold) on the turn, only adds one further parameter -- that being, the expected value of the bet, call or fold. Chen and Ankemen observe that each bet (or call) can be looked at separately from bets on the river and on the flop. This is slightly counter-intuitive, but when you think about it, it's obvious. Since you do not know what your opponent will bet on the next round (you just assign a probability to it) your bet on the turn has its own expected value which is independent of the expected value of previous bets or subsequent bets. Money that's gone in the pot has already gone. Money that's going to go into the pot will have its own expected value.
In other words, if I make a bet on the river, I assess the chance that I am winning.
If I make a bet on the turn, I assess the value of that bet, and of that bet alone. Because when we play hold'em, we are always thinking about a turn decision based on what is likely to happen on the river, we tend to see these bets as part of a whole. But this is a deception. The turn bet needs to consider what is likely to happen on the river, but it remains an independent mathematical decision.
Once you've worked that out, you can move "backwards" from the river decision outlined above, and create special theories (limit, no raises), which can be expanded into general theories (no limit, raises, reraises). The numbers get greater and the number of calculations required increases, but they don't get any more complicated.
Now, once that programming is done (a huge task), you don't need to ask a player in any poker-type betting game what hand he holds or what he thinks his opponent holds, you just need him or her to input numbers scuch as "what chance is there that you are in front?" and "what chance here is that you think your opponent will call?" plus "what chance is there that your opponent will raise (a) with a better hand and (b) with a poorer hand. Then "If opponent raises, will you call or fold?" In fact, the program could tell you whether to call or fold, based on the previous numbers.
This simple line of questioning can easily be adapted to heads-up situations on the flop and turn, because your bet on the flop has its own individual value.
The complicated part is if the user isn't a good poker player, because then the estimates inputted might be wide of the mark and the GIGO principle comes into play.
However, all is not lost. It's possible (but obscenely difficult, see the failure of Pokernomics to appear) to assign default styles of play. Or you could just get the user to input the numbers from poker tracker, making allowances for smaller sample size to give a "level of certainty" on the value of the result. So, rather than put in the numbers of "likelihood of folding/calling/raising" and "likelihood of winning", you could put in the players Pokertracker stats, put in your hand, put in the board, put in the action pre-flop, and, voila, the program outputs a result.
However, this moves away from the bit I like, the elegant simplicity of the system that just requires a few numbers to be inputted to generate an expected value. I like it so much because the response "that's not how it is in real life" can be countermanded with the line "but the numbers you put in are the only distillation of real life required to obtain the EV".
The development of the theory would start from a situation postulated by Sklansky where, with all five cards on board, you have to decide whether or not to bet. It would ignore actual numbers (those are inputted by the user) but would not require any general assessments. Everything, as it were, could be reduced to percentages.
A simple start would follow this line:
a) What is the chance if I bet that I will be called and I will lose?
b) What is the chance if I bet that I will be called and win?
c) What is the chance if I check that opponent will check and I will win?
d) What is the chance if I check that opponent will check and I will lose?
e) what is the chance if I check that opponent will bet, I will call, and I will win?
f) What is the chance if I check that opponent will bet, I will call, and I will lose?
g) What is the chance if I bet that opponent will fold and I will win?
h) What is the chance if I bet that opponent will raise, I will call, and I will lose?
i) What is the chance if I bet that opponent will raise, I will call, and I will win?
j) What is the chance if I bet that opponent will raise, I will fold, and opponent will win?
That roughly covers all situations bar re-raises, which I have excluded for the sake of brevity. Since they cover all situations, they must add up to 100%.
We can simplify this by creating two scenarios, one in which I bet, and one in which I check.
These individual scenarios also both add up to 100% (200% in total) because they alter the starting point. In one, the fact that I am betting is a given, while in the other, the fact that I am checking is a given.
Now, to this we need to add two other important pieces of information, those being the size of my bet and the size of the pot.
In this sense, limit poker is merely a "special case" (subset) of no limit poker. One in which the size of your bet is restricted to two levels, zero (= check) and a positive sum (= bet)
Now, I would contend that, once you have delineated the size of the pot, the size of your bet, and the various probabilities outlined above, then you can obtain an expected value from any size of bet. The actual cards here don't matter (in fact, the nature of the game itself doesn't matter); all that matters are the probabilities of being called and winning, being called and losing, and so on.
This doesn't eliminate the skill involved -- assigning these probabilities is one of the great arts of poker, and great players "do the right thing" through experience and through skill at assessing how likely they are to be good (and be called).
One can start at extremes. Let's take a situation where you have the nuts, and the situation where you have the worst hand possible. You are also up against two types of player, one who never folds (but never bets), and one who always folds (but never bets).
In case (a), you have the nuts against the always caller. There is $100 in the pot and its $10-$20.
Your EV if you bet is $120
Your EV if you check is $100
In case (b), you are up against the always folder.
Your EV if you bet is $100
Your EV if you check is $100
In case (c) you have a certain loser against the always caller
Your EV if you bet is minus $20
Your EV if you check is $0
In case (d) you are up against the always folder
Your EV if you bet is $100
Your EV if you check is $0.
Now, the interesting thing about these scenarios is that, if we ignore raises (for the moment), we have covered all the bases. Your hand is always somewhere between the nuts and a certain loser, and your opponent is always somehwere between a certain caller and a certain folder. If you assign percentages to these, you enter the land of "getting folds when you are losing, and getting calls when you are ahead" -- those things which give the value bettor the edge at the end.
Suppose, for example, you have no idea about your opponent. You cannot assign any probability (this is extreme, because you always have something to go on, even if it's a "default player" attribute). In that case, you have the principle of "in the beginning, everything is even money". You assume there is a half-chance that opponent will call.
Once again, you always bet the nuts (EV is now $10), and, with the certain loser, you also bet, because half the time a bet wins you $100, while half the time you lose just $20, giving a total positive EV of $40.
But, well, in real life, you will often have numbers that are far messier, say, a 35% chance of being ahead and a 72% chance of being called. The more accurate your assessment of your chances of winning/losing, and the more accurate your assessment of the chances of opponent calling/folding, the more money you will make with river bets.
As you can see, just a simple application of the possibilities quickly gets complicated, but that doesn't make it impossible to program, just rather difficult.
But this is just the river. What about turn, flop and pre-flop? What about No Limit or pot limit?
Here something written by Chen came like something of a revelation. A call or fold on the river brings about an immediate outcome. The value of that call or fold is immediately revealed.
However, a bet, call (or fold) on the turn, only adds one further parameter -- that being, the expected value of the bet, call or fold. Chen and Ankemen observe that each bet (or call) can be looked at separately from bets on the river and on the flop. This is slightly counter-intuitive, but when you think about it, it's obvious. Since you do not know what your opponent will bet on the next round (you just assign a probability to it) your bet on the turn has its own expected value which is independent of the expected value of previous bets or subsequent bets. Money that's gone in the pot has already gone. Money that's going to go into the pot will have its own expected value.
In other words, if I make a bet on the river, I assess the chance that I am winning.
If I make a bet on the turn, I assess the value of that bet, and of that bet alone. Because when we play hold'em, we are always thinking about a turn decision based on what is likely to happen on the river, we tend to see these bets as part of a whole. But this is a deception. The turn bet needs to consider what is likely to happen on the river, but it remains an independent mathematical decision.
Once you've worked that out, you can move "backwards" from the river decision outlined above, and create special theories (limit, no raises), which can be expanded into general theories (no limit, raises, reraises). The numbers get greater and the number of calculations required increases, but they don't get any more complicated.
Now, once that programming is done (a huge task), you don't need to ask a player in any poker-type betting game what hand he holds or what he thinks his opponent holds, you just need him or her to input numbers scuch as "what chance is there that you are in front?" and "what chance here is that you think your opponent will call?" plus "what chance is there that your opponent will raise (a) with a better hand and (b) with a poorer hand. Then "If opponent raises, will you call or fold?" In fact, the program could tell you whether to call or fold, based on the previous numbers.
This simple line of questioning can easily be adapted to heads-up situations on the flop and turn, because your bet on the flop has its own individual value.
The complicated part is if the user isn't a good poker player, because then the estimates inputted might be wide of the mark and the GIGO principle comes into play.
However, all is not lost. It's possible (but obscenely difficult, see the failure of Pokernomics to appear) to assign default styles of play. Or you could just get the user to input the numbers from poker tracker, making allowances for smaller sample size to give a "level of certainty" on the value of the result. So, rather than put in the numbers of "likelihood of folding/calling/raising" and "likelihood of winning", you could put in the players Pokertracker stats, put in your hand, put in the board, put in the action pre-flop, and, voila, the program outputs a result.
However, this moves away from the bit I like, the elegant simplicity of the system that just requires a few numbers to be inputted to generate an expected value. I like it so much because the response "that's not how it is in real life" can be countermanded with the line "but the numbers you put in are the only distillation of real life required to obtain the EV".
