Most people on this list won't need any further explanation of
Mike White (mykey1961?) and Ray Wotten's approach. But in case
it helps at all, here's a post I made to the Poker Academy forum
(http://forums.poker-academy.com/viewtopic.php?p=28703).

- 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.

-=-=-