Quote:Original post by JohnBolton

Quote:Original post by alvaro

Quote:Original post by JohnBolton

Quote:Original post by Rockoon1
No table should have more than 2^13 entries. One bit for each rank.

Then how would you rule out pairs and three-of-kind, etc. (with a single look-up)?

You can bitwise-OR together the kinds of the cards (represented as a 13-bit integer with a single bit set) and use a single look-up to determine if any bits are "missing" (indicating at least a pair), and detecting straights at the same time. You still need to check for flushes.

Yeah, your're right, (but it is not one lookup). The test would look something this I guess
[...]

You didn't read my code, did you? The relevant function is this:

// 5 <= n_cards <= 7bool is_high_card(unsigned *card, unsigned n_cards){  unsigned sum=0x33330000;  for(unsigned i=0;i<n_cards;++i)    sum+=card;  return !((sum&0x88880000u) || not_high_card[n_cards-5][sum&0x00001fff]);}

Quote:Original post by alvaro

You didn't read my code, did you? The relevant function is this:

// 5 <= n_cards <= 7bool is_high_card(unsigned *card, unsigned n_cards){  unsigned sum=0x33330000;  for(unsigned i=0;i<n_cards;++i)    sum+=card;  return !((sum&0x88880000u) || not_high_card[n_cards-5][sum&0x00001fff]);}

no offense.. but yuk ;-)

Quote:Original post by Rockoon1

Quote:Original post by alvaro

You didn't read my code, did you? The relevant function is this:

// 5 <= n_cards <= 7bool is_high_card(unsigned *card, unsigned n_cards){  unsigned sum=0x33330000;  for(unsigned i=0;i<n_cards;++i)    sum+=card;  return !((sum&0x88880000u) || not_high_card[n_cards-5][sum&0x00001fff]);}

no offense.. but yuk ;-)

Yeah, it's not very readable, but it's quite clever. The trick to detect flushes was an idea of a friend of mine. Did you figure out how it works?

Quote:Original post by alvaro

Quote:Original post by Rockoon1

Quote:Original post by alvaro

You didn't read my code, did you? The relevant function is this:

// 5 <= n_cards <= 7bool is_high_card(unsigned *card, unsigned n_cards){  unsigned sum=0x33330000;  for(unsigned i=0;i<n_cards;++i)    sum+=card;  return !((sum&0x88880000u) || not_high_card[n_cards-5][sum&0x00001fff]);}

no offense.. but yuk ;-)

Yeah, it's not very readable, but it's quite clever. The trick to detect flushes was an idea of a friend of mine. Did you figure out how it works?

I would say that your card representation is holding you back.



This problem isnt card-centric, its hand-centric!

Ie, a 'hand' (a collection of 'cards') should be encoded for easy evaluation. A 'card' is just a special-case of a 'hand' that happens to have only 1 card in it.

I believe 'Pokersource' encodes a HAND thusly:

13 bits representing the clubs in the hand
13 bits representing the diamonds in the hand
13 bits representing the hearts in the hand
13 bits representing the spades in the hand

In each case, a 1 bit represents a card included in the hand, and a 0 bit represents a card excluded in the hand.

There is no doubt in my mind that this representation (or one very similar to it) is optimal for the purposes of poker software (other card games could easily have different particularities)



Some things of note 'in the grand scheme' of things:

A 'hand' under this representation always consumes a precise structure regardless of how many cards it has.

Additionally there are no sorting issues at all, which often plague card-centric encodings.

Still further, it is clear that two 'hands' can by bitwise OR'd together to combine them. Card-centric encodings must concatenate strings of cards together, which is an expensive operation.

Cards can be added or removed from a hand without any iterating or memory reogranization.

And finally, this hand encoding makes rank-based hashing extremely efficient. Eliminating any need to iterate over the cards in a hand for that purpose. The hashes needed to detect flushes and straight flushes are right there already, and you are only a few OR's a way from a hash for straights and highcards.