![]() |
|
#11
|
|||
|
|||
|
[ QUOTE ]
MyKey, Am I right in saying that your procedure doesn't need a sort for the input cards. If you "train" your array with all the permutations, it would give the correct handrank no matter what order the cards come in (True?). [/ QUOTE ] This is correct. [ QUOTE ] Another thought is to reduce the size of the array by half by using the 7462 (i.e. unsigned short) possible hand ranks (ref cactus key). Most possibilities for one hand rank group (pairs) is 2860 (12 possible pairs + Combin(12,3) for the other 3 cards) for the bottom 12 bits, while using the top 4 bits for the 9 main hand ranks (high card, pairs, 2pair...). A sixty meg array feels twice as good as a 120 meg one. [img]/images/graemlins/wink.gif[/img] Thank You for the interesting posts, I am definitely watching with interest. Thank You, Ray [/ QUOTE ] I lumped everything into one big table for ease of use. If I used a different table for each # of cards, and sized them to the most efficent 1-byte/2-byte/4-byte, usage would drop from 120Mb down to 90Mb. I'm not sure that would be the most efficient in terms of speed though. There may be some time lost when the CPU loads a 16 bit value from an address that isn't a multiple of 4. Since I was using just 32 bit values, everything was aligned "properly". |
|
|