Webmaster Forum / HTML, CSS, Scripts / JavaScript / March 2010

Johannes Baagoe :

Oops - of 5-card poker hands, or simply of poker hands. It is here :
http://www.suffecool.net/poker/evaluator.html and here :
http://www.suffecool.net/poker/7462.html

In comp.lang.javascript message <w5GdnfwvJY4rsgfWnZ2dnUVZ7oRi4p2d@gigane
ws.com>, Fri, 12 Mar 2010 06:12:38, Johannes Baagoe <baagoe@baagoe.com>
posted:

I mean the number of combinations of coins that may be given, regardless
of the order in which they are handed over.  I think the modification
for the latter would be trivial in my code.

Typo : HTM too big.  Apologies.  This works :
<http://www.merlyn.demon.co.uk/js-misc0.htm#JAD>.
But the 404 text does link to the site index, in which all local links
are tested in at least one way, commonly two.

Lasse Reichstein Nielsen :

Excellent ones, as the tests show. What I use is a rather standard
exploration of all the 133 784 560 possible 7-card hands, like this :

 function allHands() {
   var count = 0;
   var types = [0, 0, 0, 0, 0, 0, 0, 0, 0];
   
   for (var c0 = 0; c0 < 52; c0++) {
     for (var c1 = c0 + 1; c1 < 52; c1++) {
        / ...
                 var type = fastHandEval(c0, c1, c2, c3, c4, c5, c6);
                 types[type >> 20]++;
                 count++;
        /...
     }
   }
   
   for (var type = 0; type < 9; type++) {
     print(types[type]);
   }
   print(count);
 }

 var now = new Date(); allHands() ; print(new Date() - now + ' ms');

All are with Chrome's v8 engine on a dual T3200 @ 2.00GHz. It is IMHO
rather amazing that it is possible to run it at all in a reasonable
time in ES. I wouldn't attempt it with Firefox / SpiderMonkey or
Opera, though, and I have nothing else. I don't know if anybody is
interested enough in trying other platforms to justify that I put
the entire code on my website before I have finalised a version that
actually does something useful.

Before your suggestions, the test ran in 37343 ms.

Making it global makes the time drop to 29165 ms. No surprise -
I could kick myself for that oversight.

Indeed. And what amazes me is how much that improves performance -
the time drops to 27499 ms, that is by nearly 6 %. I am at a loss to
explain it, since that branch is only supposed to be taken about 3 %
of the time, and this factoring out of a shift affects less that
half of instructions; I would have expected a marginal improvement
of about 1 %, not 6. I repeated the tests a couple of times with both
versions, and the ~ 6 % improvement was consistent, but it may still
have been a fluke. Do you have a better explanation ?

Sure, but avoiding them by the means of closures seems to degrade
performance. If I wrap the whole thing in a

 var texasHoldemHandEval = (function () {
   ...
   return fastHandEval;
 })();

the time of the test increases again to 32412 ms. I shall try to
figure out something better, suggestions are welcome.

On the other hand, the time drops to 26377 ms if I copy powersOf5
on entry. (Copying handValues rather degrades performance a bit, no
surprise, since is only called once.) Altogether, your suggestions have
improved speed by about 30 %, and the evaluator now reaches more than
5 million evaluations per second ! Not bad for a supposedly slow and
inefficient language...

Scott Sauyet :

Actually, what I am walking through is the *rank counts*, O ace,
1 king, 0 queen, etc: [0, 1, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 1].
Not the 7 cards.

And while I walk through them, I maintain an array of five arrays:
one for runs (it is reset to [] whenever I encounter a gap unless it
has a length of five, otherwise, the current rank is pushed on it),
one for high cards (whenever the count is 1, the current rank is
pushed on it), one for pairs (whenever the count is 2, the current
rank is pushed on it *twice*, etc.

Here, we are talking of the first, somewhat naive version of the
evaluator. It will only be executed 53,924 times - speed matters
less than clarity, especially since its overall structure helps
to explain how the second version it is used to create, the one
with the table lookup, is going to work. In both versions, we first
determine if there is a flush, and then, we exploit the rank counts
in two different ways according to whether there is one or not. The
complexity of those treatments in the first version shows the merit
of replacing them by a simple table lookup in the second.

But that argument is worthless if the first version is complicated
and messy. Therefore, I aim to make it as simple and elegant as I
can. So, instead of complicated ad hoc mechanisms for each of the
cases, I systematically use my array of arrays - it simplifies the
code. At the end of the walk, I shall use the 5 arrays as FIFOs and
shift from them, in the appropriate order according to which ones
have a non-zero length, until I have the 5 most significant ranks.

Of course, I could stop the walk before reaching the end in many
cases, like the one you mention. Or at least stop pushing on some
of the arrays. But I believe the rather complicated tests it would
entail would do more harm than good - certainly from the point of
view of clarity, and perhaps from the point of view of performance
as well. Such tests often cost more than the slight gain they give
in comparatively rare cases. Premature optimisation, and all that.

No, it does not skip the initial check, even if I use a more efficient
means in the optimised version. But after that check, I construct a
31-bit "signature" of the 13 rank counts that is slightly different
in the two cases. If there is no flush, I simply code the counts as
a 13-digit number in base 5. If there is a flush, the only thing that
matters is the presence or absence of a card in the right suit for each
of the ranks. So, I code the ranks where it is present with a digit of
2, and those where it is not with 0, still giving a 13-digit number
in base 5. Since there are at least 5 places where it is present in
the case of a flush, the sum of the digits is at least 10, whereas in
the case of no flush, that sum is always 7. Therefore, there can be no
collisions. The table doesn't care about the meaning of the signature,
it is just an access key. Incorporating the flushes increases the
number of entries by less than 10 %, from 49205 to 53924 - probably
well worth the simplification in logic.

That is what I rely on. We shall see.

Aha ! And place(5, 0, 1, [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])
which is appropriate for flushes yields 1287, and 6175 + 1287 = 7462,
giving Cactus Kev's result. It makes sense :)