Most of the fastest poker evaluators rely on representing a holding as a long integer with 52 bits indicating the presence or absence of each card in the deck.

If you are playing a poker variation with wild cards, you can extend that with an extra bit for each wild card added, and while it changes the masks for evaluation, it doesn't change the basic approach.

But is there any comparable trick available if you are interested in poker-like casino game variants like Texas Shootout? Representing a 6-deck shoe with a 312-bit integer does not sound very efficient, either for fast masking or for having any hope of holding a lookup table in memory. (Representing the number of each card present with 3 bits cuts it to 156 bits.)

I've started out on the path of enumerating all possible sets of ranks only - only a few tens of thousands of boards - and then trying to calculate for each board how many flush and non-flush hands are possible. But it has been sloooow so far. Didn't want to reinvent the wheel, if I am missing an obvious clue...

Are you sure the 52 bits thing is correct??? That seems incredibly wasteful for 5-7 bits of information....

Ahh wasn't thinking I supposed the extra space used is to save more time with lookups, computing hand values, etc.

Memory is cheap. If you wanted to represent every holdem board + hole card combo, that's C(5,7) entries which is 133,784,560. Storing them in a 64 bit int is 8 bytes each, a total of about 1GB.

Is that the best or most efficient way to do? No, but it's dumb and easy and within the capabilities of pretty much every laptop or desktop these days.

Pretty sure a 312 card deck has more than 133M 7 card combos.

I believe he was specifically referencing my comments about standard evaluators not 6 deck evaluators.

Correct

Here is a first pass at it.

1. Use a 2+2 eval method for the non-flush/non-straight flush hands. Basically rank only, so a [13][7] array.

2. If (1) evals to a 5 of a kind hand, done.

3. Determine if any straights exist. Should be able to do some bit masking instead of sorting. Note, there may be more than 1.

4. If no straights, and (1) evals to a full house or better, done.

5. Eval the straights for straight flushes. If straight flush, take highest, done.

6. If (1) evals to a full house or better, done.

7. Determine if flush exists. If yes take highest, done.

8. Output (1), done.

I guess the slowest step would be (3), maybe (7). Since (7) is further down the chain it should have less impact.

Not sure how you want to implement this. For 2 players you are looking at over 22 billion board combinations. Even with an evaluator rated at 100M/sec, you are looking at about 3 minutes to evaluate every possible board.

Random board sampling would get the job done faster at the expense of less precise calcs.

To eval all possible boards you may need to design a custom evaluator using parallel processing (threads) to get the rate up to a usable level.

This issue has been addressed in Blackjack. It is much easier to run sims on a 6- or 8-deck shoe to evaluate Blackjack strategy, then to evaluate every possible shoe composition, which is straightforward with a 1- or 2- deck game.

(1) above s/b [13]^7 array. For a non-brute force method I'm sure that could be done better with application of primes and bit operations.

I guess another tack would be to go at it board first. Enumerate over all the rank combinations, then process the flush/straight flush possibilities only if necessary. You would also need to tweak the board frequencies due to the players' holdings. Since its a 6-deck shoe all ranks are possible regardless of the players' holdings, so at least the enumeration is simple.

Yes flushless evaluation is fairly easy, 13^7 slots can be pre-evaluated and held in memory.

For 5-card hands, it's easy to store two values for the hand, one flushless and one flushed. For 7-card hands, we'd need about thirty, to hold each possible suit pattern that results in a flush. Holding 30*13^7 values in memory is enough to run us into memory issues on some machines again.

But my basic thought runs in that direction. For each board, count how many ways suits can be assigned to those cards without making a flush, and count how many ways suits can be assigned to make each flush, and add up those weights.

That can be slow - but it's still a lot faster than visiting 52^7 positions.

Going at it board-first has some advantages in that you can make some hand-vs-hand comparisons quickly: both hands unflushed, one hand makes a flush using 3 board cards the other doesn't, etc.

My prototype is still embarrassingly slow.

I'm not sure why you'd need to change approaches of other evaluators much tbh.

The 2+2 evaluator would need some very slight re-building to allow duplicate cards and handling some of the additional ranks, but the general approach would be completely unchanged. There are still only 52 distinct cards, no need to complicate things.

The evaluators using 64bit ints to represent holdings also won't change much, you can still evaluate in the same general way. You typically pass 7-card holdings to the evaluator using a single 64bit int, that obviously won't be possible here and that's really the only thing you need to work around. Pass the seven cards separately and you are pretty much good to go w/o changing the general evaluation too much.

But that's just the general evaluation of a 7-card hand, maybe it's a different part that is giving you troubles? Not entirely clear to me what you are trying to do exactly tbh.

You should be able to use 6 bits per card, no? That leaves you 6*7 = 42 bits required. Even if you wanted to cover each card uniquely, that is 9 bits * 7 = 63, which a 64 bit long would do.

If you tried to feed Ah-Ah-Ah-Kh-Qh into the standard 2+2 evaluator I'm sure you'd get some kind of error. The entire memory table would need to be rebuilt. Not saying that can't be done though.

Sure, you can pass 7 cards within a 64bit value even for multiple decks - just not in the way described above where you represent cards as single bits set. On that representation you can do all kinds of evaluations and checks using simple bit arithmetic.

When you represent cards like you suggest above then that's no longer possible, so you'd probably need to change the representation for the evaluation anyway. May just pass the cards separately in that case.

FYI, the 2+2 evaluator I use passes the arguments as an array of ints.

Also, passing 6 identical cards to the 2+2 evaluator results in an incorrect hand value. So you would indeed need to rebuild the memory table to account for the new ranked hands such as 5 of a kind.