Open Source 6/7 Card Evaluators

[M_White]

[M_White]

I've completed a state driven 7 card Eval table that can be used when speed is more important than memory consumption.

1 card states 52
2 card states 1326
3 card states 22100
4 card states 84448
5 card states 152607
6 card states 352443

The table consists of 31874856 integers.

Rank = Eval[Eval[Eval[Eval[Eval[Eval[Eval[52+c1]+c2]+c3]+c4]+c5]+c6]+c7]

Each state is a multiple of 52.

State = 0 represents some form of error, and all vectors from state 0 point back to state 0.

State_1 = Eval[52+Card_1]

EVal[State_n+Card_(n+1)] = State_(n+1)

Eval[State_6+Card_7] = Hand Rank for those 7 cards.

Total size of the Table is 121Mb

[terence]

[M_White]

[darse]

Here is a high-level explanation of the nested table approach, with an example. This is a description of the system I use, which I think is the same as the one in the 2+2 thread (there might be some minor differences, but they should be pretty close since it is "the natural thing to do", for some value of "natural").

Imagine six separate tables, corresponding to the number of cards we have currently processed. Each table holds an index value (or a pointer to a particular location) into the next table. It's like a network of pointers, expanding at each stage, but having a branching factor much less than 52 because each set of cards is sorted and reduced to only the essential information.

Let's suppose the first card is the 9h. It is represented as the 1-card hand "9h". The table entry for the 9h contains 52 indices (or pointers) corresponding to the 52 cards in the deck. The pointer for 9h[9h] might point to -1, indicating an error, since a legal hand can't have two 9h.

The second card is the Kc. The hand ID is the full hand sorted by rank and suit, so we currently have the hand "Kc9h". This entry in the second table is pointed to from two places in the first table, namely 9h[Kc] and Kc[9h]. There are 52 out-going pointers for this hand, two of which point to an error state.

The third card is the Kh. Kc9h[Kh] => KhKc9h. There are six different paths through the network leading to this state.

The fourth card is the Qc. KhKc9h[Qc] => KhKcQc9h. We retain the suit information because both hearts and clubs have a potential flush after 7 cards. If this card had been the Qd, then neither diamonds nor clubs could make a potential flush. They would be mapped to a "meta-suit" for no possible flush, which I will call "o" for "offsuit" or "other". Thus, the Qd would have produced KhKc9h[Qd] => KhKoQo9h.

The fifth card is the 2h. KhKcQc9h[2h] => KhKoQo9h2h. Clubs are now irrelevant with respect to possible flushes.

The sixth card is the 5h. KhKoQo9h2h[5h] => KhKoQo9h5h2h. Each entry of the sixth (and largest) table also has 52 out-going pointers, but instead of an index, they contain hand values.

The seventh card is the 7s. KhKoQo9h5h2h[7s] = value(KKQ97) which is 3844. If this had been the 7h, the table entry would contain the value of K9752f, which is 6367.

Note that a 6-card hand with five flush cards can ignore the offsuit card, as it cannot have a bearing on the final value. Thus, the large 6-card table can be reduced in size a little by using a "meta-rank" for "don't care", merging many cases into one. We cannot eliminate the smallest rank of a 6-card flush, however, because it might be part of a straight flush after the seventh card is known.

Note also that the sequential composition of hand IDs uses a lot less memory than more simplistic approaches. This can be further reduced if we dispense with the duplicate cards pointing to an error state, but the indexing gets trickier.

There are two main reasons this method is much faster for systematic enumeration tasks. First, we move most of the work out of the inner-most loops, and do it once instead of repeating it many times. Second, we ensure cache coherence to minimize the number of expensive accesses to main memory. For example, each fetch of an 8K block contains exactly the information that will be needed for the upcoming enumeration cases.

This technique might also be useful for hybrid Monte Carlo simulations over sets of cases, such as all possible river cards for a given 4-card board, or all possible 2-card hands in connection with a random board.

- Darse.

[Sparky2007]

Thanks alot for that explanation Darse. This technique makes alot of sense. I am in the process of converting this to java at the minute, I will let you all know how it performs during an enumeration of 7 card hands.

I assume from the 2+2 thread, that a mix between this (for enumeration) and the older evaluation functions would be a good idea.

[M_White]

[ChessMan]

[alan]

An evaluator generates a single integer representing hand strength, right?

How are flushes handled? It seems that you would need 1277 equivalence classes for flushes. Is this correct?

[Sparky2007]

I have converted the code to Java but when running it, I am getting an out of bounds exception at one point.

I am not an expert on the differences between c++ and java but I think my conversion of the following line may be incorrect.

[darse]

[Sparky2007]

I have converted the code to Java as best I understand the difference between the two languages but I am still unable to get through the entire process of assigning the 7 card hand values at the end of the process.

Hopefully some of you more familiar could give it a shot?

[alan]

[ChessMan]

[thomas]

I am new to this forum and also fairly new to poker AI, so my question may be a bit uninformed.

Could we not just precalculate all hand strengths?

((52 choose 7) + (52 choose 6) + (52 choose 5) + (52 choose 4) + (52 choose 3) + (52 choose 2)) / 4 = 39 259 047.8

I divide by four because I figure the different combinations of suits should yield the same strength.

If I calculate the result as a probability that the hand will win the game and then bin it into 256 discrete values, i.e. a byte I should be able to store the complete set in a bit lesds than 40 mb of memory.

Is there a flaw in my reasoning?

Thomas

[Sparky2007]

Thanks ChessMan, yes I have made that change, the java code creates the Id's now with no errors, but fails at the stage where the actual rankings are assigned at the end.

There must be a difference in the way the java code creates the ID's as they are not being created equally.

I found that a __int64 in C is a 64bit unsigned integer. In java there are no such things as unsigned integers. A long is a Java 64bit signed integer, so I think this is where the ID's are not being created correctly.

[Steve Brecher]

[Steve Brecher]

[Sparky2007]

Hi Steve, yes I have noticed that using the >>> removes java's signed representation but unfortunately there must be some difference that I am not noticing. I would greatly appreciate if for testing could someone who has gotten the C++ version working, to maybe print out the hand ID's as they are created.

his would allow me to see where my code is working differently (hopefully) and if not, narrow the problem down to some other section.

Thanks alot everyone

[thomas]