Optimizing hand-evaluation algorithm for Poker-Monte-Carlo-Simulation

Question

I\'ve written an equilator for Hold\'em Poker as a hobbyproject. It works correctly, but there is still one thing I am not happy with: In the whole process of simulating han

Answer 1

I've written a rather fast poker hand evaluator in the past. I used a rather different representation from yours, and I think that was the key to performance.

I represented a hand of at most 7 cards by a 64-bit integer; bit 4 was for the two of hearts, bit 5 for the two of diamonds, 6 for the two of spades, 7 for the two of clubs, 8 for the three of hearts, and so forth.

You first check for straight flushes; form hh = h & (h>>4) & (h>>8) & (h>>12) & (h>>16). If hh is nonzero, then you have a straight flush beginning at its high bit.

Then you check for four-of-a-kinds; form hh = h & (h>>1) & (h>>2) & (h>>3) & 0x1111...1. If hh is nonzero, you've got yourself a four-of-a-kind.

At this point, you want to find out which ranks have three-of-a-kind and which ranks have pairs. Similar to the four-of-a-kind case, form bitmasks telling you which ranks have at least three cards, which ranks have at least two cards, and which ranks have at least one card. (Think about sorting each nibble of the hand.) If popcount(threes) + popcount(twos) >= 2, you have a full house to find.

Flush and straight conditions are straightforward to check. And, at this point, so are three-of-a-kind, two pair, and pair conditions.

A nice feature of this approach is that it can straightforwardly return an integer representing the rank of the hand, reducing hand comparison to a bunch of bit-fiddling to preprocess the hands and then a single integer comparison. (Exactly as you're doing, now that I look at your post again.) It also directly operates on 7-card hands if written properly, eliminating the need to iterate over all subsets of 5 cards in the hand.