64 bit word = one poker hand?

Why bother? Save 4 bytes per hand? How many hands do you need to have in memory at the same time?

Quote: JB

Then if you number each card from 0 to 51, and each hand from 0 to 133784559, you can convert 7 card indexes to a hand index as follows:

Choose7[card7] + Choose6[card6] + Choose5[card5] + Choose4[card4] + Choose3[card3] + Choose2[card2] + card1

...where card7 is the highest-numbered card index and card1 is the lowest-numbered card index (it is critical that the card indexes are sorted from highest to lowest).

Then, to convert a hand index (0 ... 133784559) to card indexes, use the following logic:

int card1 = hand_index, card2, card3, card4, card5, card6, card7;

card7 = 51;        while (Choose7[card7] > card1) { card7--; } card1 -= Choose7[card7];
card6 = card7 - 1; while (Choose6[card6] > card1) { card6--; } card1 -= Choose6[card6];
card5 = card6 - 1; while (Choose5[card5] > card1) { card5--; } card1 -= Choose5[card5];
card4 = card5 - 1; while (Choose4[card4] > card1) { card4--; } card1 -= Choose4[card4];
card3 = card4 - 1; while (Choose3[card3] > card1) { card3--; } card1 -= Choose3[card3];
card2 = card3 - 1; while (Choose2[card2] > card1) { card2--; } card1 -= Choose2[card2];

...where hand_index is the hand index from 0 to 133784559. The result will be 7 card indexes in sorted order (card1 being the lowest-numbered card index, and card7 the highest-numbered one), just as was required for the function to compute the hand index.

Hope that helps!

These concepts are gold; they are invaluable to making a poker analyzer.

The Wizard has some of the same info at the bottom of this page, but his requires numbers sorted low to high, and is not quite as straight forward:
Video Poker Programming Tips

Quote: weaselman

Why bother? Save 4 bytes per hand? How many hands do you need to have in memory at the same time?

It depends on the application. For example, if you're writing something in Java then this would be the way to go since Java's memory constraints are restrictive. If you're creating a binary data file then you definitely want to go this route to minimize the disk space used for it.

Another reason is to standardize the sequence of the cards (that is, to store combinations and not permutations). It would obviously be quicker to use a 64-bit number and just bit-shift the card indexes if memory is not an issue but speed is, but even if you do that you'll still have to sort the card indexes.

Quote: JB

It depends on the application. For example, if you're writing something in Java then this would be the way to go since Java's memory constraints are restrictive.

Not sure what you mean by this. Java long is 8 bytes just like in (64 bit) C.

Quote:

If you're creating a binary data file then you definitely want to go this route to minimize the disk space used for it.

Nah... Gzip will pack it better than you ever would anyway.

Quote:

Another reason is to standardize the sequence of the cards (that is, to store combinations and not permutations). It would obviously be quicker to use a 64-bit number and just bit-shift the card indexes if memory is not an issue but speed is, but even if you do that you'll still have to sort the card indexes.

I don't understand what this means. Sort the indexes? Why?

Quote: weaselman

Not sure what you mean by this. Java long is 8 bytes just like in (64 bit) C.

Yes but the default amount of memory you can use for arrays is pretty limited, when designing an applet for the web anyway.

Quote: weaselman

Nah... Gzip will pack it better than you ever would anyway.

If adding another layer of complexity and slowing things down is worth it, sure.

Quote: weaselman

I don't understand what this means. Sort the indexes? Why?

For a 7-card hand, there are 7! = 5040 ways to arrange the card indexes. You don't want to store each unique hand 5040 times in an array with 674274182400 subscripts (consuming about 4.9 terabytes); it would be better to sort the card indexes and store each hand once in an array with 133784560 subscripts. Even so, that's about 1GB of memory if you use 64-bit integers, and of course only half of that if you use 32-bit integers.

Quote: JB

Yes but the default amount of memory you can use for arrays is pretty limited, when designing an applet for the web anyway.

How much is it? I have not done applets for quite a while, don't remember anymore... Who uses defaults nowadays anyway?

Quote:

If adding another layer of complexity and slowing things down is worth it, sure.

Piping data through gzip is hardly "complexity". Especially, was compared.to your mapping algorithm :-) As for speed, reading and writing gzipped files is generally faster, than unpacked ones. Even if there is no significant reduction in size, it does not take any longer because io is done in parallel with gzip CPU activity.

Quote:

For a 7-card hand, there are 7! = 5040 ways to arrange the card indexes. You don't want to store each unique hand 5040 times

Ah, yeah, that makes sense. Though, I am still not sure what kind of application requires storing this many hands.
If you are doing a simulator, and just want to log every hand, you'd have to store as many hands as you play anyway, regardless of how they are represented.

Quote: weaselman

How much is it? I have not done applets for quite a while, don't remember anymore... Who uses defaults nowadays anyway?

I don't know what the specific limit is, but I ran into problems trying to create an applet that generates video poker strategies. I would assume that those who don't specifically tinker with Java's memory settings are the ones who use defaults.

Quote: weaselman

Piping data through gzip is hardly "complexity". Especially, was compared.to your mapping algorithm :-) As for speed, reading and writing gzipped files is generally faster, than unpacked ones. Even if there is no significant reduction in size, it does not take any longer because io is done in parallel with gzip CPU activity.

We may be arguing two different things here. I see my method to map hands as the most efficient and simple method possible. Using compression only comes into play if you're saving or loading the array to/from a file (or memory stream).

Quote: weaselman

Ah, yeah, that makes sense. Though, I am still not sure what kind of application requires storing this many hands.
If you are doing a simulator, and just want to log every hand, you'd have to store as many hands as you play anyway, regardless of how they are represented.

For a calculator it would be useful. For example, if you know two hole cards, loop through the other 5 cards, calculate the combination, and look up the hand type in the array; this is much faster than calling a separate function to determine the hand rank due to the overhead of calling a function 2,118,760 times.

I do everything in MS-SQL. It's so easy to program and store results. I'm perfectly happy with resolving only 5000 rounds of poker per second. Since there are only 7462 possible 5 card poker outcomes, it's easy to store the results in a table.