On 4-Jan-07, at 9:23 AM, Darse Billings wrote:
>
> I'm thinking it might be advantageous to represent cards keeping the
> rank and suit separated (4+2 bits), rather than having to unravel the
> 6-bit representation for integers 0-51. Now the unordered rank pattern
> can be determined quickly with bit operations, (28 bits = 268 million
> table entries), and the suit pattern determines the flush exceptions.
>

Specifically:

2c 001000 2d 001001 2h 001010 2s 001011
3c 001100 3d 001101 3h 001110 3s 001111
4c 010000 4d 010001 4h 010010 4s 010011
5c 010100 5d 010101 5h 010110 5s 010111
6c 011000 6d 011001 6h 011010 6s 011011
7c 011100 7d 011101 7h 011110 7s 011111
8c 100000 8d 100001 8h 100010 8s 100011
9c 100100 9d 100101 9h 100110 9s 100111
Tc 101000 Td 101001 Th 101010 Ts 101011
Jc 101100 Jd 101101 Jh 101110 Js 101111
Qc 110000 Qd 110001 Qh 110010 Qs 110011
Kc 110100 Kd 110101 Kh 110110 Ks 110111
Ac 111000 Ad 111001 Ah 111010 As 111011

Note that an unordered set of 5 cards can be held in a single 32-bit
integer, which can then be converted to a hand value with a table
look-up, and to a (sorted) canonical representative with another
(small) table look-up...

For 7-card functions, we likely need a composition process (starting
with 4 cards), using a chain of table look-ups, as discussed in the
2+2 thread.

Note also that smaller sets of cards can be subsumed into the large
tables, using a rank of 0000 as a "don't care" condition. For example,
all flush hands of 5, 6, or 7 cards are contained in the same table.

Sorry if this is vague and unintelligible (I'm not fully coffeed yet).
I have some Python code that more clearly defines what I'm talking
about, which I might make available when it's finished. I'm sure
others are better equipped to optimize the hell out of the idea... :)

- Darse.