Sign in to follow this  
PaulCesar

Poker Odds

Recommended Posts

Hello, There is probably a fairly simple solution to something like this out there, but I decided I wanted to implement something like the showdown percentages you see on the television (texas holdum), to do so I need to have the percentages of hitting a hand. No problem I think, I can do basic outs calculation. That solves the chance of hitting a card that goes toward the hand, but it does not solve hitting the hand completely unless you already have 4 of the 5 cards on the table. Thats a problem because its the showdowns from the flop and pre-flop that i want to show calculations from. What I have done so far is im capable of getting the number of outs to finish each individual hand, at the current state of the game. This can be determined no sweat, and is done before the hands displayed to the user anyways. But heres the problem, lets say they have this after the flop K J 10 2 3 they need a Q and a K of any suit to make a straight, so we have 8 outs when they get a Q or a K they will have 4 outs so (8/47)*(4/46) would be the chance of hitting the hand (part of what i would show) The problem is there are times when this obviously gets alot more complicated then simply halving the number of outs each time... what i need help with is if there is a method of calculating the chance% of hitting a hand, from any point in the hand, if anyone has any sudgestions they are more then welcome. Thanks Richard

Share this post


Link to post
Share on other sites
Ah,

But this is not testing if the hand would win or not, this is testing the chance of if they would COMPLETE the hand or not. IE: if they would finish that straight, or hit the flush.

Richard

EDIT: Given the chance% of hitting particular hands I can successfully come up with the Win%, so what im trying to deduce is in essence only a piece of the final product.

[Edited by - PaulCesar on June 9, 2005 9:40:29 PM]

Share this post


Link to post
Share on other sites
I've actually thought about doing this myself. Though I was thinking about approaching the problem a little differently. I was going to write a program that would simulate a large number of random hands, and keep track of the wins/loses with those hands. This would then give me a table for every possible hand combination with the percentages of wins to loses with that hand.

I wasn't really sure how much the odds would change with the number of players at the table either so I was going to run it for different numbers of players playing the hand.

Finally, I was going to use the tables from those runs to play against different AI's such as aggressive players (will play lower percentages), conservative players (will fold if they percentage is too low), etc. and see how the tables change with that too.

Just my thoughts on the process,
The_Ethernopian

Share this post


Link to post
Share on other sites
You are somewhat on the idea, but this doesent require any precalculation, it should be "fairly" known, there is no guestiment and no taking other players into account. But im pretty sure to a point on what im doing now, but there is a bug.

For instance, Say I want to know the probability of hitting a flush given 2 unsuited cards. According to http://www.pokerupdate.com/pokerodds.htm that is ~1.8%. Now how was that determined?

What I did was create a recursive function that did the following. (Please note its one that is only meant to test flush %)

1) Took in a given hand
2) If the hand was a flush pass back 1 as the chance% (100%)
3) If the hand is a 4 card hand (1 more card is needed, pass back the number of outs)
4) If the hand had less then 4 cards to the flush, recursively call the function, copying the deck, and adding a card that would help complete the flush.

and now... for what you have all been waiting for... the very off function

[code]
/*
Flush Odd Percentages
*/

float Calc_Flush(const CARDVALUE Cards[7], int* number_of_outs)
{
// The number of cards availiable
int CardsDrawn = 0;
int NextNewCard = 0; // used for adding fake OUT cards
float chance = 0; // Used for holding the cumulative chance
float fnChance = 0; // Merges the percentage of getting the next card(s)
int nOuts = 0;
int nTotalOuts = 0;

// Count the cards into suits
int Suit[4] = {0,0,0,0};
for(int i=0; i<7; i++)
if(Cards[i].valid == true)
{
CardsDrawn++;
Suit[Cards[i].suit]++;
}
else
{
NextNewCard = i;
}

// Get the total number of outs
nTotalOuts = 52-CardsDrawn;

// Sort through each suit
for(int n=0; n<4; n++)
{
// Detect if the suit has a shot at being a flush
if((5-Suit[n]) <= (7-CardsDrawn))
{

// Variable for holding the number of outs
if((5-Suit[n]) > 0)
nOuts += 13 - Suit[n];
else
nOuts = -1;

// We recurse through everything (for percentages) up to the flush draw
if(Suit[n] < 5)
{
// Create a new card set to pass
CARDVALUE IncCards[7];
memcpy(IncCards, Cards, sizeof(CARDVALUE)*7);

// Add a new (fake) card
IncCards[NextNewCard].val = 0;
IncCards[NextNewCard].suit = n;
IncCards[NextNewCard].valid = true;

fnChance += Calc_Flush(IncCards, NULL);
}
else
{
// The next card is the one, just get the shot at getting the card
//fnChance += (float)nOuts / (float)nTotalOuts;
fnChance = 1;
}
}
else
{
// No shot at a flush
}
}

// Set the starting chance
chance = (float)nOuts / (float)nTotalOuts; // the chance of pulling one card
chance *= fnChance; // the chance of pulling the rest of a suit

if(nOuts < 0)
chance = 1;

// Pass back the number of outs (if applicable)
if(number_of_outs != NULL)
*number_of_outs = nOuts;

// Return the chance %
return chance;
}
[/code]



USE:

Currently I am multiplying the result of this by the number of cards that have not been used + 1. Im pretty sure this will double/triple my odds or do any manipulation necessary based on where you are in the hand.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I haven't looked at your code so I can't tell you what is wrong with it, but I would strongly recommend you to simply iterate through the 2 million possible cases (or doing Monte Carlo simulation as suggested above) counting how many of them are flushes. On a modern computer this can be done in a second or so. Also, it is by far the simplest and least error prone solution. Further, even if you do manage to compute the odds of getting a flush, or a straight, or a three of a kind, independently, you can't just add those odds together to get the total probability of beating another players hand.

Share this post


Link to post
Share on other sites
Im pretty sure I can recall Monte Carlo from back in the day (Analytical Statistics) and its requirement for inputs, simulated randomization completely makes it unorthodox for what I want, which is pure statistical computation.

And as far as going through million possiable hands (14^7) (14 because we would need to seperate unknown cards in the lookup table) would require well over 250MB RAM for a lookup table. This is a tad bit too high for anything but high end systems. In fact if I added anything really detailed about the hand probablitity I would hit the 2GB process resource barrier quickly, and just... well frankly would be over-over kill.

As far as win %, while this is all theoretical, and the concept was ran by my old statistics professor who claimed it SHOULD work (spent quite a while going through the processes), the calculations dont need to be done PERFECTLY, just QUICKLY and FAIRLY ACCURATLY. The plan was to get the %chance of figuring getting each potential hand (split not only into the common, but into lower further denominators such as FLUSH_KING_HIGH, STRAIGHT_5_HIGH, etc. We then calculate the unknown players probababily given 2 unknowns, which will give us the chances for the particular players. In order to get the Win% we would be multiplying the unknown chance by the number of players, giving us the chance of particular competitive hands showing up. Given that, we would not be difficult to simply figure out the average WIN% (the chance that your item would be larger then that of the the approx table total).

EDIT:

BTW, Another reason to not do it, is it can be modeled, meaning it can be achieved much more accuratly and much faster For instance, to calculate a flush off off of a draw

Lets say we have only pocket cards here As and Kd

We currently can still get a flush in anything, so we have 50 outs, so caluclate the 4 types of outs and reiterate


Chances of pulling a particular card on the flop
----------
As Kd - Xc = 13/50
As Kd - Xs = 12/50
As Kd - Xd = 12/50
As Kd - Xh = 13/50

Now we go to the next card (Im just going to model one direction to prove a point, you would normaly model all possiable flushes and add them together i believe)

As Kd - Xd = 12/50
As Kd Xd - Xd = 11/49
As Kd Xd Xd - Xd = 10/48
As Kd Xd Xd Xd - Xd = 9/47
* 2^spares

So now to figure out the probability from preflop we just need to multiply these values together

((12/50)*(11/49)*(10/48)*(9/47)*4)+ // the *4 is because there are 4 probable sets based on 4 out of 5 cards
((12/50)*(11/49)*(10/48)*(9/47)*4)+
((13/50)*(12/49)*(11/48)*(10/47)*(9/47))+
((13/50)*(12/49)*(11/48)*(10/47)*(9/47))= 1.8383%








[Edited by - PaulCesar on June 10, 2005 1:41:44 PM]

Share this post


Link to post
Share on other sites
To compute the winning chances just deal all possible hands and count, as it has already been suggested. A really fast hand evaluator will help. Using a few bit tricks you can evaluate several million hands per second, and in a few seconds you'll get the exact winning probabilities

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by alvaro
To compute the winning chances just deal all possible hands and count, as it has already been suggested. A really fast hand evaluator will help. Using a few bit tricks you can evaluate several million hands per second, and in a few seconds you'll get the exact winning probabilities


To be specific, I can get ~2 million hand evaluations per second on my AMD XP 2000+ processor, using 100% Visual Basic 6 code.

The hand eval is only general purpose and still could be optimised to take advantage of correlations between successive evaluations. But at this point I think thats a lot of overkill.

Considering that given 2 hole cards and a flop, there are only 47 cards left with 2 cards to come. 47 * 46 / 2 = 1081 different combinations of turn and river.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this