Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Optimising combinatorial iterations by filtrationby Moron (Curate) |
on Mar 08, 2007 at 16:46 UTC ( [id://603857]=perlquestion: print w/replies, xml ) | Need Help?? |
Moron has asked for the wisdom of the Perl Monks concerning the following question:
This might be more algorithmic than pure Perl as a question, on the other hand the availability of methods in CPAN modules does form a boundary for the current state of the problem ... On the TV Holdem Poker shows, they often have a calculator (presumably a program) that shows onscreen which hand has what winning percentage at a given moment. Last year I had a go (but got stuck and put it on the backburner) at trying to create my own, to test different people's opinions on whether a particular hand is favourite to win for a given set of community cards (betting history etc. being, albeit unrealistically, ignored for the purpose of this calculator). Math::Combinatorics and its Algorithmic brother can generate for example all the permutations of nine cards to use for testing the in the heads-up situation, 11 for three players and so on, BUT...
Even in just the heads-up case, the number of raw (unfiltered) combinations to test that would be generated by said module is going to be 52C2 * 50C5 (er something over five trillion ( To cut that story short, it is clear that many combinations can be eliminated by filtration and further that if the iterations through the combinations could be ordered so as to be able to group them by hand value yet more reduction in permutations can be achieved or at the very least, the capability to jump along the so-ordered list of combinations by some means to reduce the actual iterations to a manageable number. The problem is that there doesn't seem to be a way to control the module in that way ... or is there? ... or is there some other clever way to make this programmable? Obviously ... it's been done on TV so there must be... ;) Update: and even if the module can be tweaked to skip some iterations, it isn't trivial to calculate where to jump to, for example, in the 23569 case, three of the cards could match the suit of a suited two card holding making the hand value different from the cases where no flush is held and even an ordering method that overcomes that might miss holdings of 4X and 78 where some of these are runs and the rest are straight flushes. So ordering the combinations usefully remains to my mind an obstacle to finding a feasible solution along above lines. -M Free your mind
Back to
Seekers of Perl Wisdom
|
|