Yes, that link shows exactly what I just told you. It's for generic hand types, which is an approximation of equity. It isn't used when you specify exact hands.

for exact hands one can easily do that and get reasonable speed. for something like AA vs AA-66,A8s+,ATo+,KT+ you start get too many combos for exhaustive enumeration. For the given example you have 1,366,418,592 combos This takes pokerstove 1.35 seconds giving a speed of 1billion hands per second with exhaustive enumeration. Not even the two plus two evaluator is fast enough for that.

Would be great if someone actually familiar with the inner workings of pokerstove would reply.

Yes, the range you show is generic hand types, not exact hands. For ranges that is all you need because you are not interested in an exact suited hand matchup, and the average for the generic hand is actually what you want.

If your point was that the lookup table is used for hand ranges, you're probably right. Sorry if I was unclear.

It seems that we were talking about different things, yes. You did state in your post that you talked about exact hands, I missed that. Sorry.

Here you can download a free program I wrote (and source code) that you may find interesting:

http://pawellmajewskyy.atspace.co.uk/


The program asks for cards of 2 players and computes the probability of winning (or splitting the pot).

Enjoy!

I know this thread is old but in case people get in here in 2015, there is now an open source code for poker stove on github:

https://github.com/andrewprock/pokerstove

Have fun.

Hi guys, I'm putting together a mockup for an equity based EV calculation tool and I need to integrate an equity calculator that can do the following:

1. Calculate a hand's equity against a range
2. Count the number of combinations in a highlighted range
3. (Ideally) Show the range breakdown-the percentage of the range that hit sets, top pair, 2nd pair...etc. (Equilab and Combonator both perform all 3 of these functions).

I know that pokerstove has open sourced it's code, but if i understand the software correctly it will perform only #1, not #2-3 of the above specifications. Is anyone aware of open source code I can refer the developer to for use in the software?

Maybe it's all stuff you do manually.

You start with a hand vs hand evaluator. There are many open source / available, big thread on here "7 card hand evaluators". PokerStove source too most likely). And a function to extract the numerous individual hands comprising a range. e.g. AKs = {AcKc, AsKs, AdKs, AhKh}

You input a specific hand for hero, and a range for villain.

Then you get all the combos in villain's range (removing for hero's cards, board etc), and loop the evaluator to calc your overall equity. This gives you 2 and 1.

3 depends on your evaluator being able to tell you the rank of each evaluation outcome also, rather than just win/loss.

Yeah that seems doable, was hoping there was something already out there that performed all 3 (or at least 1-2) that I could use.

I had a question on ranges and how they are done. I'm trying to understand the poker source code but and unclear on how the random hands are dealt

I realize each player has to be randomly selected so that Player 1 is not always dealt first.

After that however is the hand randomly taken from the possible range or is it by card ?

For example if Player 1 can have KK, QQ and 33 thus 18 different hands

OR

Is it draw from four different kings, four different Queens, four different 3's thus 12 random options and then select the second card based on available ranges from the first card ?

Or am I still missing how ranges are done?

I am trying to understand the logic since based on a program im writing my equity varies too much depending on the order of the players when I start having overlapping cards and hands between players.

Thanks,

The biggest problem people typically have when using ranges in an equity calculator is a subtle one. I had it myself.

Let's say that guy 1 has the range of just "AA" and guy 2 has the range of KK+. Let's say that our algorithm is to randomly select a hand from his range for guy 1, then for guy 2. We do this by generating all the possible hands. For guy 1, his total range is the 6 specific AA hands, and for guy 2, he has 6 AA hans and 6 KK hands.

OK, so we select a hand for guy 1. Let's say it's AsAc. Now we need to remove all the specific hands from guy 2s range that intersect this. This leaves us 3 AA hands and 6 KK hands.

Whoops! Now when we randomly select from guy 2's range, we will get 1/3 AA hands and 2/3 KK hands, throwing off the distribution.

There is surely more than one solution to this. What I personally did was this:

I randomly select a hand from their expanded range for each player. I do not limit the ranges based on hands that have already been selected. Once I have selected all hands, I look to see if there's an overlap. If there is, I throw away the *whole* process and start again from scratch. This way there is guaranteed to not be a bias caused by selecting a hand from one player limiting the hands of another.

It means I have to do the selection process way more often than otherwise - how often depends on how tight the ranges are. In my example above, it happens quite a lot, obviously, 3/12 times.

(Note: I have not seen pokerstove's source code, I don't know how he did it at all)

Thanks for the reply.

When you throw away the whole process do you mean cancel the iteration or just continue to loop on the same player until a hand does not collide?

The code I was attempting does the following:

1) Player 1 has a specific hand such as 9d 9s
2) Opponent1 Has AA,KK, QQ, 44,22
3) Opponent2 Has KK, AQs 44

Start the simulation such as 0 < 500000
Successfully random the opponents
Draw from the first opponents range (Never a collision) since no ranges are taken

Draw from second opponents range and do a check to see if the cards in that hand collide with the first. If they do grab another random hand until i have one that does not collide.

Maybe this is my problem is that i keep trying on the second opponent until I get a match without collision ?

And when you say ranges do you remove ones that cannot happen if a board is provided that would have one of the cards in the range? For example if an Ac was on the flop then there is no way to be drawn aces 6 different ways ?

Also, I assume you are matching poker stove and pro poker tools ?

Thanks again for your feedback.

When you come across a conflict, you have to discard every hand you gave out this round and start again.

You can't just discard hands on the 2nd person if they conflict with the first, because clearly, you'll have the problem I described.

First person gets AcAd. Then any hand with Ac or Ad in it will be rejected for the 2nd person. If you just keep going until you get a match, then your pool of acceptable hands will be 3 AA hands and 6 KK hands. So someone who "should" have AA 50% and KK 50% will end up with AA only 33%

And yeah, I used propokertools and other places as a reference. My evaluator works with any kind of poker that you can describe with sort of a description language that I made, so for some games that don't have simulators, I have to hope that it's right. I made a test suite for it that I run whenever I make any changes. It contains a set of normal cases, and every edge case that I've ever come across.

Thanks, I didnt even consider redrawing in the same loop to cause that kind of difference in the results. I will change my code and throw out the whole comparison to see if I match.

And just to clarify, you have or have not yet taken out any board cards that might have been specified with the ranges ?

Yes, I remove any known dead cards. This has a similar effect - if you know 2 particular aces are dead, then KK+ is now 1/3 AA and 2/3 KK. But this is actually correct I think.

My reasoning is, in my previous example, you would get different results depending on who you had draw first. In this dead cards example, the results are always the same no matter how you pick cards.

What language(s) did you use? Just curious I want to do something identical.

It seems correct for player 1 to block player 2, though. PPT gives AA player 77.4% equity here. I'm not sure how to fix this ordering issue for the general case, though.

The first solver I made was in plain C. The most current one is C++ (but I haven't worked on it in years)

I've gone back and forth on this all day, to be honest. I think I had things backwards and that a 1:1 ratio of KK to AA for player 2 is wrong, and a 2:1 ratio is correct. But the point is, if you're not careful, you can get the wrong answer due to ordering.

For the general case, maybe it would be best to weight the probability of drawing cards for each player by the frequency of blockers in the other player's range? This would solve the ordering problem, I think. For example, second player in the AA vs AA-KK would only have a 50% probability of drawing any given Ace.

See this thread: http://archives1.twoplustwo.com/show...fpart=all&vc=1

Last post explains what PokerStove tried and later had to revert due to bias.

Juk

Thanks for the read.

Agree thanks for the link. Great reading those older posts, funny how time flys

I used C++ to get this work. Randomizing both the players who are dealt first and throwing out collisions allowed me to get the correct results.