Hi to all my poker chums who have been patient and understanding in
these difficult times? The website is now up and ready for testing.
Have had a look around and then set up an account - remember choose a
name that you like and feel comfortable with because it will be yours
and the place where everyone will go to check you out so make sure you
are happy with the name.
Once you have done that you can then set your site to represent your
sense of style and choose the widgets that you want. You can also
upload pictures, videos and podcast most are self explanatory but if
you need any help email me or post a message in the forum and I will
be happy to assist in any way possible.
I am aiming to launch the site to the general public on January 1st
2009 at 2pm (GMT), so your feedback will be most welcomed.
SO LETS PLAY POKER!!!
I have downloaded pokersource using Cygwin.
I would like to build and test pypoker-eval and eventually try to
build a Windows version of poker-network and poker-engine.
My question regards python, is there a specific python binary/build
that I should use such as ActivePython, Python 2.x from python.org, or
Cygwin python?
Additionally are there any Windows libraries that have been built? I
did find a link on the pokersource development site for a Windows Wiki
however there was no contents.
Just had some time from poker because there was a big race meeting and
I wanted to spend some time doing other stuff. Had a nice little touch
on Aiden O'Brien's Dylan Thomas in the King George VI and Queen
Elizabeth Stakes at 6/4 for a few quid so my weekend was sorted. If
only I could get such sure things every week it would make life so
much easier.
Later went clubbing in some good forsaken night club in Wiltshire -
what a waste of time. Me and my mate pulled but all I got at the end
of the night was just a grope and a phone number for future fun. Tell
you the truth I am not in any rush to make contact.
The girl I was really after was a nice mixed race red head (I must
admit I do like the odd red head even if it is dyed). However she was
with her boyfriend a yardie type Rastafarian, with a group of
colleagues that look like they carried guns and knives as a fashion
accessory. So all I did was make eye contact and smile
acknowledgement. Inn the meantime my friend made the cheesiest chat up
line work for him and pulled a right dog. She was 27 going on 77 - a
plain Jane who was taken in by the line ' if I said you had a
beautiful body would you hold it against me ' (jeez), surprise
surprise it worked. Unlucky for me her friend came as a package hence
my grope and phone number.
Talking of chat up lines how about this one for a true reflection of a
man's intention. I found it on a BBC website today I must try it one day.
Okay, so I came over here to ask you to dance, but I'm kind of
concerned. I mean, we could hit it off really well, end up having a
few drinks, next thing you know you're giving me your number because
I'm too shy to ask for it, I finally get up the nerve to call and we
take in a movie, have some dinner, I relax, you relax, we go out a few
more times, get to know each other's friends, spend a lot of time
together, then finally have get past this sexual tension and really
develop this intense sex life that is truly incredible, decide our
relationship is solid and stable, so we move in together for a while,
then a few months later get married, I get a promotion, you get a
promotion, we buy a bigger house. You really want kids, but I really
want freedom, but we have a kid anyway, only to find that I am
resentful, the sparks start to fade and to rekindle them we have two
more lovely kids, but now I work too much to keep up with the bills,
have no time for you, and you're stress! ed and stop taking really
good care of yourself, so to get past our slow sex life and my
declining self-confidence I turn to an outside affair for sexual
gratification. You find out because I'm careless and a lousy liar, you
throw me out (justifiably so) and we have to explain to the kids why
mommy and daddy are splitting up. That's just too sad. Think about the
children. For God's sake, if you dance with me and we hit it off,
let's just keep it sexual, because we both know where it's going .
(sent in by Christian Miller)
PK
http://www.pokerknave.com
I am looking to integrate a hand evaluator into my current poker
software. A lot of the actions of my poker player were essentially
hardcoded for the final rounds of play of texas hold'em hands. I am
looking to improve its play and be able to get the value of five card
hands.
I have seen sites like these:
http://www.suffecool.net/poker/evaluator.html
But was unable to translate that C code into C# or VB.NET because of
my meager knowledge with bitwise operations. I was wondering if anyone
has a good algorithm or some good code for evaluating hands.
I would like to be able to pass a five card hand to a function and
have it send a back a numerical representation of the hand exactly
like the below code. Does anyone have any ideas?
Hello pokersource people,
There is another email list dedicated to discussion about the
pokersource libraries:
https://mail.gna.org/listinfo/pokersource-users/
It has a different focus than this list, with discussion about some
applications being developed using the pokersource components. Past
traffic is archived on the web.
-Michael M
Is it possible to use Keith Rules C# evaluator for multi-way
match-ups? I haven't succeeded to get it working, and I don't know
why. Maybe you can? The results from my modified version of Keith's
example code were consistently about 1% of PokerStove's and
PokerBoliden's.
I tried to get multi-way functionality by modifying Keith's code in
the section "Using Pocket Queries in code" from his article
http://www.codeproject.com/csharp/MoreTexasHoldemAnalysis1.asp .
public static void three()
{
// A Pocket Query Returns an array of all
// hands that meet the criterion.
ulong player1 = Hand.ParseHand("Jc 2c");
ulong player2 = Hand.ParseHand("9d 7d");
ulong player3 = Hand.ParseHand("7h 2h");
ulong board = Hand.ParseHand("");
// Holds stats
long player1Wins = 0, player2Wins = 0, player3Wins = 0,
ties = 0, count = 0;
// Iterate through 10000 trials.
for (int trials = 0; trials < 10000; trials++)
{
// Pick a random board
ulong boardMask
= Hand.RandomHand(board, player1 | player2 |
player3, 5);
// Create a hand value for each player
uint player1HandValue =
Hand.Evaluate(boardMask | player1, 7);
uint player2HandValue =
Hand.Evaluate(boardMask | player2, 7);
uint player3HandValue =
Hand.Evaluate(boardMask | player3, 7);
// Calculate Winners
if (player1HandValue > player2HandValue &&
player1HandValue > player3HandValue)
{
player1Wins++;
}
else if (player2HandValue > player1HandValue &&
player2HandValue > player3HandValue)
{
player2Wins++;
}
else if (player3HandValue > player1HandValue &&
player3HandValue > player2HandValue)
{
player3Wins++;
}
else
{
ties++;
}
count++;
}
// Print results
Console.WriteLine("Player1: {0:0.0}%",
(player1Wins + ties / 3.0) / ((double)count) * 100.0);
Console.WriteLine("Player2: {0:0.0}%",
(player2Wins + ties / 3.0) / ((double)count) * 100.0);
Console.WriteLine("Player3: {0:0.0}%",
(player3Wins + ties / 3.0) / ((double)count) * 100.0);
}
Best Regards and biggest Thank yous!
Thank you for your response!!! Let me know how much
you would like for this.
I hope i filled out the information that you liked
with enough info. let me know
Glenn
--- Loic Dachary <loic@...> wrote:
>
> "glennprime" <glennprime@...> writes:
>
> > I am looking for someone who can build a SIMPLE
> Java standalone applet
> > that uses poker-engine and poker-eval. I am
> willing to pay for the
> > app.
> > This donsnt need to have great graphics. Again,
> very simple. But i am
> > not a programmer so I need some help. Please
> contact me for details.
> > glennprime@...
>
> Hi,
>
> I'm willing to implement this for you.
>
> I need to know what you need though ;-) Can you
> describe a simple
> use case, with bullet points ? You can write it down
> at
>
http://pokersource.info/developers/specifications/java-client.html
> under "Use Case".
>
> You can also post a bid request on
> RentACoder.com and guru.com to find
> professionals willing to do the job.
>
> Cheers,
>
> --
> +33 1 76 60 72 81 Loic Dachary mailto:loic@...
> http://dachary.org/loic/gpg.txt sip:loic@...
> Latitude: 48.86962325498033 Longitude:
> 2.3623046278953552
> ----------
>
________________________________________________________________________________\
____
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
"glennprime" <glennprime@...> writes:
> I am looking for someone who can build a SIMPLE Java standalone applet
> that uses poker-engine and poker-eval. I am willing to pay for the
> app.
> This donsnt need to have great graphics. Again, very simple. But i am
> not a programmer so I need some help. Please contact me for details.
> glennprime@...
Hi,
I'm willing to implement this for you.
I need to know what you need though ;-) Can you describe a simple
use case, with bullet points ? You can write it down at
http://pokersource.info/developers/specifications/java-client.html under "Use
Case".
You can also post a bid request on RentACoder.com and guru.com to find
professionals willing to do the job.
Cheers,
--
+33 1 76 60 72 81 Loic Dachary mailto:loic@...http://dachary.org/loic/gpg.txt sip:loic@...
Latitude: 48.86962325498033 Longitude: 2.3623046278953552
----------
I am looking for someone who can build a SIMPLE Java standalone applet
that uses poker-engine and poker-eval. I am willing to pay for the app.
This donsnt need to have great graphics. Again, very simple. But i am
not a programmer so I need some help. Please contact me for details.
glennprime@...
No takers then, seems a shame - would more money promote more takers I
wonder? Get back to me any one is interested.
Regards,
John.
John Washington wrote:
Darse,
Thanks for the reply - I dont expect there to be a player edge here but
am interested in what the optimal strategy and house edge is, along
with looking at the code with interest in the hopes of getting better
at using the code, and programming it myself.
Regards,
John.
Darse Billings wrote:
I would also expect that all or close to all hands should play,
getting at least 3:1 odds, favourable implied odds, and a free
pass to the showdown. 32o wins just under 33% against a random
hand, and of course worse against the best of two random hands,
but it still might be near the playable region. I haven't done
any math to support that intuition, but I fully expect that an
optimal strategy is *far* from easy to describe. You have to
compute the EV for every possible flop and turn, and the outcome
for every possible board. The opponent hand distribution can be
pre-computed, and updated as board cards are revealed by zeroing
the impossible cases. All in all, that's a pretty big job, but
should be quite doable with today's machines.
- Darse.
On 4-Mar-07, at 10:46 AM, Darse Billings wrote:
>
> I just did a quick read of the rules. If I haven't misunderstood
> how the game is played, an optimal strategy will involve many hands
> that call the raise with draw odds, and then recover some equity
> by betting after the flop (favourable implied odds from +EV hands
> against the opponent's known distribution). With the exception
> of big pairs and perhaps some potentially dominating hands (e.g.
> AK), the preflop all-in is not a very powerful action, because a
> mere 60-40 advantage reduces the leverage considerably, and must
> abandon the implied odds from optionally flat betting one unit on
> the flop and turn.
>
> The good news is that it is not a difficult game to solve, because
> the EV can be computed for each case against the known
distribution.
> I suppose the game designers did this when defining the game, to
> ensure a guaranteed profit against optimal play (and much better
> against typical humans, who are much weaker than they imagine).
> However, there have been many promotions in the past where the
> house failed to do the math properly, and ended up taking the
> worst of it, so it might be worth looking into.
>
>
> On 4-Mar-07, at 3:33 AM, JRWashington wrote:
>
>> Hi,
>>
>> I am interested in a program which optimally solves the wager
works
>> casino game of Texas Hold'em shoot out, I am also interested
in the
>> variance but not as much as the ideal strategy. My expectation
is
>> that the optimal strategy would be all in or fold. The rules
and the
>> bot behavior can be found
>>
>> http://casino.virgingames.com/GameDetails.do?menu=STRP&gameid=0068-0
>>
>> Bottom line is there are 2 possible pot states, you are
effectively
>> always the small blind as one of the bots will always raise,
leaving
>> either a 3 unit pot or a 4 unit pot.
>>
>> The you have the option to go all in, or fold, the bot will
always
>> call your all in. An all in is worth 8x your ante so makes
either a
>> 19 unit pot or a 20 unit pot and seeing 5 cards.
>>
>> The eval example would almost seem to do everything you need,
apart
>> from, picking the stronger of the bots hand to play with.
>>
>> I am willing to pay upto $50 (by paypal most likely) for the
house
>> advantage with an all in or fold, a proper strategy table/or
>> application for an all in or fold strategy, and the source
code with
>> compilation instruction and code comments.
>>
>> If the optimum strategy is not all in or fold (eg it is call
and play
>> down the streets), then, I will pay $100 if you are prepared
to solve
>> that - and provide the same as above - application, HA and
source with
>> comments, as it looks like more work.
>>
>> Many Thanks,
>>
>> John.
>>
>
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.6/709 - Release Date: 03/03/2007 08:12
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.6/709 - Release Date: 03/03/2007 08:12
Thanks for the reply - I dont expect there to be a player edge here but
am interested in what the optimal strategy and house edge is, along
with looking at the code with interest in the hopes of getting better
at using the code, and programming it myself.
Regards,
John.
Darse Billings wrote:
I would also expect that all or close to all hands should play,
getting at least 3:1 odds, favourable implied odds, and a free
pass to the showdown. 32o wins just under 33% against a random
hand, and of course worse against the best of two random hands,
but it still might be near the playable region. I haven't done
any math to support that intuition, but I fully expect that an
optimal strategy is *far* from easy to describe. You have to
compute the EV for every possible flop and turn, and the outcome
for every possible board. The opponent hand distribution can be
pre-computed, and updated as board cards are revealed by zeroing
the impossible cases. All in all, that's a pretty big job, but
should be quite doable with today's machines.
- Darse.
On 4-Mar-07, at 10:46 AM, Darse Billings wrote:
>
> I just did a quick read of the rules. If I haven't misunderstood
> how the game is played, an optimal strategy will involve many hands
> that call the raise with draw odds, and then recover some equity
> by betting after the flop (favourable implied odds from +EV hands
> against the opponent's known distribution). With the exception
> of big pairs and perhaps some potentially dominating hands (e.g.
> AK), the preflop all-in is not a very powerful action, because a
> mere 60-40 advantage reduces the leverage considerably, and must
> abandon the implied odds from optionally flat betting one unit on
> the flop and turn.
>
> The good news is that it is not a difficult game to solve, because
> the EV can be computed for each case against the known
distribution.
> I suppose the game designers did this when defining the game, to
> ensure a guaranteed profit against optimal play (and much better
> against typical humans, who are much weaker than they imagine).
> However, there have been many promotions in the past where the
> house failed to do the math properly, and ended up taking the
> worst of it, so it might be worth looking into.
>
>
> On 4-Mar-07, at 3:33 AM, JRWashington wrote:
>
>> Hi,
>>
>> I am interested in a program which optimally solves the wager
works
>> casino game of Texas Hold'em shoot out, I am also interested
in the
>> variance but not as much as the ideal strategy. My expectation
is
>> that the optimal strategy would be all in or fold. The rules
and the
>> bot behavior can be found
>>
>> http://casino.virgingames.com/GameDetails.do?menu=STRP&gameid=0068-0
>>
>> Bottom line is there are 2 possible pot states, you are
effectively
>> always the small blind as one of the bots will always raise,
leaving
>> either a 3 unit pot or a 4 unit pot.
>>
>> The you have the option to go all in, or fold, the bot will
always
>> call your all in. An all in is worth 8x your ante so makes
either a
>> 19 unit pot or a 20 unit pot and seeing 5 cards.
>>
>> The eval example would almost seem to do everything you need,
apart
>> from, picking the stronger of the bots hand to play with.
>>
>> I am willing to pay upto $50 (by paypal most likely) for the
house
>> advantage with an all in or fold, a proper strategy table/or
>> application for an all in or fold strategy, and the source
code with
>> compilation instruction and code comments.
>>
>> If the optimum strategy is not all in or fold (eg it is call
and play
>> down the streets), then, I will pay $100 if you are prepared
to solve
>> that - and provide the same as above - application, HA and
source with
>> comments, as it looks like more work.
>>
>> Many Thanks,
>>
>> John.
>>
>
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.6/709 - Release Date: 03/03/2007 08:12
I would also expect that all or close to all hands should play,
getting at least 3:1 odds, favourable implied odds, and a free
pass to the showdown. 32o wins just under 33% against a random
hand, and of course worse against the best of two random hands,
but it still might be near the playable region. I haven't done
any math to support that intuition, but I fully expect that an
optimal strategy is *far* from easy to describe. You have to
compute the EV for every possible flop and turn, and the outcome
for every possible board. The opponent hand distribution can be
pre-computed, and updated as board cards are revealed by zeroing
the impossible cases. All in all, that's a pretty big job, but
should be quite doable with today's machines.
- Darse.
On 4-Mar-07, at 10:46 AM, Darse Billings wrote:
>
> I just did a quick read of the rules. If I haven't misunderstood
> how the game is played, an optimal strategy will involve many hands
> that call the raise with draw odds, and then recover some equity
> by betting after the flop (favourable implied odds from +EV hands
> against the opponent's known distribution). With the exception
> of big pairs and perhaps some potentially dominating hands (e.g.
> AK), the preflop all-in is not a very powerful action, because a
> mere 60-40 advantage reduces the leverage considerably, and must
> abandon the implied odds from optionally flat betting one unit on
> the flop and turn.
>
> The good news is that it is not a difficult game to solve, because
> the EV can be computed for each case against the known distribution.
> I suppose the game designers did this when defining the game, to
> ensure a guaranteed profit against optimal play (and much better
> against typical humans, who are much weaker than they imagine).
> However, there have been many promotions in the past where the
> house failed to do the math properly, and ended up taking the
> worst of it, so it might be worth looking into.
>
>
> On 4-Mar-07, at 3:33 AM, JRWashington wrote:
>
>> Hi,
>>
>> I am interested in a program which optimally solves the wager works
>> casino game of Texas Hold'em shoot out, I am also interested in the
>> variance but not as much as the ideal strategy. My expectation is
>> that the optimal strategy would be all in or fold. The rules and the
>> bot behavior can be found
>>
>> http://casino.virgingames.com/GameDetails.do?menu=STRP&gameid=0068-0
>>
>> Bottom line is there are 2 possible pot states, you are effectively
>> always the small blind as one of the bots will always raise, leaving
>> either a 3 unit pot or a 4 unit pot.
>>
>> The you have the option to go all in, or fold, the bot will always
>> call your all in. An all in is worth 8x your ante so makes either a
>> 19 unit pot or a 20 unit pot and seeing 5 cards.
>>
>> The eval example would almost seem to do everything you need, apart
>> from, picking the stronger of the bots hand to play with.
>>
>> I am willing to pay upto $50 (by paypal most likely) for the house
>> advantage with an all in or fold, a proper strategy table/or
>> application for an all in or fold strategy, and the source code with
>> compilation instruction and code comments.
>>
>> If the optimum strategy is not all in or fold (eg it is call and play
>> down the streets), then, I will pay $100 if you are prepared to solve
>> that - and provide the same as above - application, HA and source with
>> comments, as it looks like more work.
>>
>> Many Thanks,
>>
>> John.
>>
>
I just did a quick read of the rules. If I haven't misunderstood
how the game is played, an optimal strategy will involve many hands
that call the raise with draw odds, and then recover some equity
by betting after the flop (favourable implied odds from +EV hands
against the opponent's known distribution). With the exception
of big pairs and perhaps some potentially dominating hands (e.g.
AK), the preflop all-in is not a very powerful action, because a
mere 60-40 advantage reduces the leverage considerably, and must
abandon the implied odds from optionally flat betting one unit on
the flop and turn.
The good news is that it is not a difficult game to solve, because
the EV can be computed for each case against the known distribution.
I suppose the game designers did this when defining the game, to
ensure a guaranteed profit against optimal play (and much better
against typical humans, who are much weaker than they imagine).
However, there have been many promotions in the past where the
house failed to do the math properly, and ended up taking the
worst of it, so it might be worth looking into.
On 4-Mar-07, at 3:33 AM, JRWashington wrote:
> Hi,
>
> I am interested in a program which optimally solves the wager works
> casino game of Texas Hold'em shoot out, I am also interested in the
> variance but not as much as the ideal strategy. My expectation is
> that the optimal strategy would be all in or fold. The rules and the
> bot behavior can be found
>
> http://casino.virgingames.com/GameDetails.do?menu=STRP&gameid=0068-0
>
> Bottom line is there are 2 possible pot states, you are effectively
> always the small blind as one of the bots will always raise, leaving
> either a 3 unit pot or a 4 unit pot.
>
> The you have the option to go all in, or fold, the bot will always
> call your all in. An all in is worth 8x your ante so makes either a
> 19 unit pot or a 20 unit pot and seeing 5 cards.
>
> The eval example would almost seem to do everything you need, apart
> from, picking the stronger of the bots hand to play with.
>
> I am willing to pay upto $50 (by paypal most likely) for the house
> advantage with an all in or fold, a proper strategy table/or
> application for an all in or fold strategy, and the source code with
> compilation instruction and code comments.
>
> If the optimum strategy is not all in or fold (eg it is call and play
> down the streets), then, I will pay $100 if you are prepared to solve
> that - and provide the same as above - application, HA and source with
> comments, as it looks like more work.
>
> Many Thanks,
>
> John.
>
Hi,
I am interested in a program which optimally solves the wager works
casino game of Texas Hold'em shoot out, I am also interested in the
variance but not as much as the ideal strategy. My expectation is
that the optimal strategy would be all in or fold. The rules and the
bot behavior can be found
http://casino.virgingames.com/GameDetails.do?menu=STRP&gameid=0068-0
Bottom line is there are 2 possible pot states, you are effectively
always the small blind as one of the bots will always raise, leaving
either a 3 unit pot or a 4 unit pot.
The you have the option to go all in, or fold, the bot will always
call your all in. An all in is worth 8x your ante so makes either a
19 unit pot or a 20 unit pot and seeing 5 cards.
The eval example would almost seem to do everything you need, apart
from, picking the stronger of the bots hand to play with.
I am willing to pay upto $50 (by paypal most likely) for the house
advantage with an all in or fold, a proper strategy table/or
application for an all in or fold strategy, and the source code with
compilation instruction and code comments.
If the optimum strategy is not all in or fold (eg it is call and play
down the streets), then, I will pay $100 if you are prepared to solve
that - and provide the same as above - application, HA and source with
comments, as it looks like more work.
Many Thanks,
John.
Actually, I wrote some C++ code to do exactly this - I actually worked out a
minimal perfect hash for the representations. Basically, an evaluation is a
sort of the 5 cards (which is usually not necessary since I generate cards
in sorted order already in my source code) followed by the calculation of
the hash followed by a single lookup. Calculating the hash is pretty quick -
it's all integer math with data in registers already. The only hard part is
the sorting - I use sorting networks to make this as quick as possible. I'm
trying to figure out how to build a version of the sorting networks (a topic
I love!) that doesn't involve any JMPs - there's a discussion of that in:
http://www.iguanarama.com/programming/
I'm still buggering around with it. It's pretty quick - I use it in my home
rolled pokerbot. I can do exhaustive searches of the post-flop possibilities
in a fraction of a second on my Pentium IV.
I stuck the classes (card & phand) with a brief description of what I did on
my website:
http://www.iguanarama.com/programming/poker_bot.html
Enjoy, Sn0rt.
-----Original Message-----
From: pokersource@yahoogroups.com [mailto:pokersource@yahoogroups.com] On
Behalf Of Darse Billings
Sent: Thursday, January 04, 2007 3:07 PM
To: pokersource@yahoogroups.com
Subject: Re: [pokersource] 2+2 thread on super fast evaluators
Having suggested the bit-friendly representation, I'm now working on making
it obsolete. :) If we roll-up the cards
6 bits at a time and compose a 4-card 24-bit index look-up with 3-card
18-bit look-ups, then the card representation doesn't matter. Any amount of
computation can be encoded in the magic table values, with sufficient head
scratching.
I don't know much about the relative speeds of operations on modern
architectures. Maybe Google knows. (I suspect that cache coherence is at
least as important though).
You're right about testing -- it's hard to know all of the clever short-cuts
today's optimizing compliers can come up with. If we take the test set from
a file, then a comparison version doing no-ops might be used to estimate the
overhead.
One advantage of this scheme is that the cards in the file can be from a
truly random source, such as random.org.
- Darse.
On 4-Jan-07, at 12:19 PM, Jeffrey Siegal wrote:
>> On 4-Jan-07, at 9:23 AM, Darse Billings wrote:
>>>
>>> I'm thinking it might be advantageous to represent cards keeping the
>>> rank and suit separated (4+2 bits), rather than having to unravel
>> the
>>> 6-bit representation for integers 0-51. Now the unordered rank
>> pattern
>>> can be determined quickly with bit operations, (28 bits = 268
>> million
>>> table entries), and the suit pattern determines the flush
>> exceptions.
>>>
>>
>> Specifically:
>>
>> 2c 001000 2d 001001 2h 001010 2s 001011 3c 001100 3d 001101 3h 001110
>> 3s 001111 4c 010000 4d 010001 4h 010010 4s 010011 5c 010100 5d 010101
>> 5h 010110 5s 010111 6c 011000 6d 011001 6h 011010 6s 011011 7c 011100
>> 7d 011101 7h 011110 7s 011111 8c 100000 8d 100001 8h 100010 8s 100011
>> 9c 100100 9d 100101 9h 100110 9s 100111 Tc 101000 Td 101001 Th 101010
>> Ts 101011 Jc 101100 Jd 101101 Jh 101110 Js 101111 Qc 110000 Qd 110001
>> Qh 110010 Qs 110011 Kc 110100 Kd 110101 Kh 110110 Ks 110111 Ac 111000
>> Ad 111001 Ah 111010 As 111011
>>
>> Note that an unordered set of 5 cards can be held in a single 32-bit
>> integer, which can then be converted to a hand value with a table
>> look-up, and to a (sorted) canonical representative with another
>> (small) table look-up...
> If you're going to do a table lookup, is there some significant
> advantage from the binary representation over, say,
>
> index = card0+52*(card1 + 52*(card2 ... ))
>
> which results in a smaller table (though not by enough to pack another
> card into 32 bits).
>
> Is the binary manipulation faster than multiply/add on current
> processors?
>
> Also (directed at everyone), in doing these tests, you should try some
> mode of usage other than sequentially iterating through hands, since
> that introduces a large degree of locality and may (depending on the
> algorithm) reduce the cost of table lookups and/or unpredictable
> branches. (This applies to the existing poker-eval code as well.) For
> example, a good test would be evaluating randomly generated hands
> against each other, with a control test to remove the cost of
> generating the hands.
>
Yahoo! Groups Links
Most people on this list won't need any further explanation of
Mike White (mykey1961?) and Ray Wotten's approach. But in case
it helps at all, here's a post I made to the Poker Academy forum
(http://forums.poker-academy.com/viewtopic.php?p=28703).
- Darse.
-=-=-
Here is a high-level explanation of the nested table approach,
with an example. This is a description of the system I use,
which I think is the same as the one in the 2+2 thread (there
might be some minor differences, but they should be pretty close
since it is the natural thing to do, for some value of "natural").
Imagine six separate tables, corresponding to the number of cards
we have currently processed. Each table holds an index value (or
a pointer to a particular location) into the next table. It's
like a network of pointers, expanding at each stage, but having
a branching factor much less than 52 because each set of cards
is sorted and reduced to only the essential information.
Let's suppose the first card is the 9h. It is represented as the
1-card hand "9h". The table entry for the 9h contains 52 indices
(or pointers) corresponding to the 52 cards in the deck. The
pointer for 9h[9h] might point to -1, indicating an error, since
a legal hand can't have two 9h.
The second card is the Kc. The hand ID is the full hand sorted by
rank and suit, so we currently have the hand "Kc9h". This entry
in the second table is pointed to from two places in the first
table, namely 9h[Kc] and Kc[9h]. There are 52 out-going pointers
for this hand, two of which point to an error state.
The third card is the Kh. Kc9h[Kh] => KhKc9h. There are six
different paths through the network leading to this state.
The fourth card is the Qc. KhKc9h[Qc] => KhKcQc9h. We retain the
suit information because both hearts and clubs have a potential
flush after 7 cards. If this card had been the Qd, then neither
diamonds nor clubs could make a potential flush. They would be
mapped to a "meta-suit" for no possible flush, which I will call
"o" for "offsuit" or "other". Thus, the Qd would have produced
KhKc9h[Qd] => KhKoQo9h.
The fifth card is the 2h. KhKcQc9h[2h] => KhKoQo9h2h. Clubs are
now irrelevant with respect to possible flushes.
The sixth card is the 5h. KhKoQo9h2h[5h] => KhKoQo9h5h2h. Each
entry of the sixth (and largest) table also has 52 out-going
pointers, but instead of an index, they contain hand values.
The seventh card is the 7s. KhKoQo9h5h2h[7s] = value(KKQ97)
which is 3844. If this had been the 7h, the table entry would
contain the value of K9752f, which is 6367.
Note that a 6-card hand with five flush cards can ignore the
offsuit card, as it cannot have a bearing on the final value.
Thus, the large 6-card table can be reduced in size a little
by using a "meta-rank" for "don't care", merging many cases
into one. We cannot eliminate the smallest rank of a 6-card
flush, however, because it might be part of a straight flush
after the seventh card is known.
Note also that the sequential composition of hand IDs uses
a lot less memory than more simplistic approaches. This can
be further reduced if we dispense with the duplicate cards
pointing to an error state, but the indexing gets trickier.
There are two main reasons this method is much faster for
systematic enumeration tasks. First, we move most of the
work out of the inner-most loops, and do it once instead of
repeating it many times. Second, we ensure cache coherence
to minimize the number of expensive accesses to main memory.
For example, each fetch of an 8K block contains exactly the
information that will be needed for the upcoming enumeration
cases.
This technique might also be useful for hybrid Monte Carlo
simulations over sets of cases, such as all possible river
cards for a given 4-card board, or all possible 2-card hands
in connection with a random board.
- Darse.
-=-=-
Nobody? Please, I need it badly... Thanks:)
--- In pokersource@yahoogroups.com, "olixnet" <spam@...> wrote:
>
> Well, now I finally know what does each packet mean, but I was unable
> to determine how to send/receive the packets. I mean - how to
> encode/decode the packets? Do I have to use TCP or UDP connection? I
> think poker-network uses SOAP, am I right? Could you, please, send me
> just an example of a communication string? I need something concrete
> to start with... Thank you very much!
>
Having suggested the bit-friendly representation, I'm now
working on making it obsolete. :) If we roll-up the cards
6 bits at a time and compose a 4-card 24-bit index look-up
with 3-card 18-bit look-ups, then the card representation
doesn't matter. Any amount of computation can be encoded
in the magic table values, with sufficient head scratching.
I don't know much about the relative speeds of operations
on modern architectures. Maybe Google knows. (I suspect
that cache coherence is at least as important though).
You're right about testing -- it's hard to know all of the
clever short-cuts today's optimizing compliers can come up
with. If we take the test set from a file, then a comparison
version doing no-ops might be used to estimate the overhead.
One advantage of this scheme is that the cards in the file
can be from a truly random source, such as random.org.
- Darse.
On 4-Jan-07, at 12:19 PM, Jeffrey Siegal wrote:
>> On 4-Jan-07, at 9:23 AM, Darse Billings wrote:
>>>
>>> I'm thinking it might be advantageous to represent cards keeping the
>>> rank and suit separated (4+2 bits), rather than having to unravel
>> the
>>> 6-bit representation for integers 0-51. Now the unordered rank
>> pattern
>>> can be determined quickly with bit operations, (28 bits = 268
>> million
>>> table entries), and the suit pattern determines the flush
>> exceptions.
>>>
>>
>> Specifically:
>>
>> 2c 001000 2d 001001 2h 001010 2s 001011
>> 3c 001100 3d 001101 3h 001110 3s 001111
>> 4c 010000 4d 010001 4h 010010 4s 010011
>> 5c 010100 5d 010101 5h 010110 5s 010111
>> 6c 011000 6d 011001 6h 011010 6s 011011
>> 7c 011100 7d 011101 7h 011110 7s 011111
>> 8c 100000 8d 100001 8h 100010 8s 100011
>> 9c 100100 9d 100101 9h 100110 9s 100111
>> Tc 101000 Td 101001 Th 101010 Ts 101011
>> Jc 101100 Jd 101101 Jh 101110 Js 101111
>> Qc 110000 Qd 110001 Qh 110010 Qs 110011
>> Kc 110100 Kd 110101 Kh 110110 Ks 110111
>> Ac 111000 Ad 111001 Ah 111010 As 111011
>>
>> Note that an unordered set of 5 cards can be held in a single 32-bit
>> integer, which can then be converted to a hand value with a table
>> look-up, and to a (sorted) canonical representative with another
>> (small) table look-up...
> If you're going to do a table lookup, is there some significant
> advantage from the binary representation over, say,
>
> index = card0+52*(card1 + 52*(card2 ... ))
>
> which results in a smaller table (though not by enough to pack
> another card into 32 bits).
>
> Is the binary manipulation faster than multiply/add on current
> processors?
>
> Also (directed at everyone), in doing these tests, you should try
> some mode of usage other than sequentially iterating through hands,
> since that introduces a large degree of locality and may (depending
> on the algorithm) reduce the cost of table lookups and/or
> unpredictable branches. (This applies to the existing poker-eval
> code as well.) For example, a good test would be evaluating randomly
> generated hands against each other, with a control test to remove the
> cost of generating the hands.
>
On 2007-01-04, at 09:47 , Darse Billings wrote:
>
> On 4-Jan-07, at 9:23 AM, Darse Billings wrote:
> >
> > I'm thinking it might be advantageous to represent cards keeping the
> > rank and suit separated (4+2 bits), rather than having to unravel
> the
> > 6-bit representation for integers 0-51. Now the unordered rank
> pattern
> > can be determined quickly with bit operations, (28 bits = 268
> million
> > table entries), and the suit pattern determines the flush
> exceptions.
> >
>
> Specifically:
>
> 2c 001000 2d 001001 2h 001010 2s 001011
> 3c 001100 3d 001101 3h 001110 3s 001111
> 4c 010000 4d 010001 4h 010010 4s 010011
> 5c 010100 5d 010101 5h 010110 5s 010111
> 6c 011000 6d 011001 6h 011010 6s 011011
> 7c 011100 7d 011101 7h 011110 7s 011111
> 8c 100000 8d 100001 8h 100010 8s 100011
> 9c 100100 9d 100101 9h 100110 9s 100111
> Tc 101000 Td 101001 Th 101010 Ts 101011
> Jc 101100 Jd 101101 Jh 101110 Js 101111
> Qc 110000 Qd 110001 Qh 110010 Qs 110011
> Kc 110100 Kd 110101 Kh 110110 Ks 110111
> Ac 111000 Ad 111001 Ah 111010 As 111011
>
> Note that an unordered set of 5 cards can be held in a single 32-bit
> integer, which can then be converted to a hand value with a table
> look-up, and to a (sorted) canonical representative with another
> (small) table look-up...
If you're going to do a table lookup, is there some significant
advantage from the binary representation over, say,
index = card0+52*(card1 + 52*(card2 ... ))
which results in a smaller table (though not by enough to pack
another card into 32 bits).
Is the binary manipulation faster than multiply/add on current
processors?
Also (directed at everyone), in doing these tests, you should try
some mode of usage other than sequentially iterating through hands,
since that introduces a large degree of locality and may (depending
on the algorithm) reduce the cost of table lookups and/or
unpredictable branches. (This applies to the existing poker-eval
code as well.) For example, a good test would be evaluating randomly
generated hands against each other, with a control test to remove the
cost of generating the hands.
I did almost the same thing about 12 years ago when CPU cycles and RAM
were more expensive.
I created a table that returned a two values, one if the hand was not
suited and one if it was suited. If the suited value was non-zero
(meaning the hand could be suited and would improve in value if
suited) then it was tested if it was suited or not.
The good part of this approach is the saved cycles when not needed.
The bad part is some hands took longer to evaluate.
Once I got it working I used it for a couple of hand evaluator ideas,
thought about extending it for 7-card hands where the memory
considerations got much larger, then lost interest as I had other
things going on taking my "free" time, like changing diapers on my
then baby girl (now in 7th grade).
I wish I could add to the topic some but I can add that this is the
path I thought to explore as well so I wish you good luck and look
forward to some results.
On 1/4/07, Darse Billings <darse@...> wrote:
>
> Quite some time ago, "Cactus Kev" created a webpage about
> his fast 5-card hand eval:
>
> http://www.suffecool.net/poker/evaluator.html
>
> It exploits the equivalence classes of poker hands, where
> there are only 7462 distinct hand values. His indexing
> function is primitive, but the potential for very fast
> table-based evaluators is clear. The bottleneck is now
> in computing the hash index, and the 2+2 thread offers
> some clever tricks to do that in under 50 cycles per hand.
>
> - Darse.
>
>
> On 3-Jan-07, at 8:28 PM, Michael Maurer wrote:
>
> > There is a fascinating thread on 2+2 about building the next
> > generation of poker hand evaluators. Several posters have reported
> > 7-card hand eval rates well over 100M hands per second. The
> > approaches use "a lot" of memory, but nothing you would notice on your
> > desktop box.
> >
> > The thread is here:
> > http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=all
> >
> > -Michael M
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
On 4-Jan-07, at 9:23 AM, Darse Billings wrote:
>
> I'm thinking it might be advantageous to represent cards keeping the
> rank and suit separated (4+2 bits), rather than having to unravel the
> 6-bit representation for integers 0-51. Now the unordered rank pattern
> can be determined quickly with bit operations, (28 bits = 268 million
> table entries), and the suit pattern determines the flush exceptions.
>
Specifically:
2c 001000 2d 001001 2h 001010 2s 001011
3c 001100 3d 001101 3h 001110 3s 001111
4c 010000 4d 010001 4h 010010 4s 010011
5c 010100 5d 010101 5h 010110 5s 010111
6c 011000 6d 011001 6h 011010 6s 011011
7c 011100 7d 011101 7h 011110 7s 011111
8c 100000 8d 100001 8h 100010 8s 100011
9c 100100 9d 100101 9h 100110 9s 100111
Tc 101000 Td 101001 Th 101010 Ts 101011
Jc 101100 Jd 101101 Jh 101110 Js 101111
Qc 110000 Qd 110001 Qh 110010 Qs 110011
Kc 110100 Kd 110101 Kh 110110 Ks 110111
Ac 111000 Ad 111001 Ah 111010 As 111011
Note that an unordered set of 5 cards can be held in a single 32-bit
integer, which can then be converted to a hand value with a table
look-up, and to a (sorted) canonical representative with another
(small) table look-up...
For 7-card functions, we likely need a composition process (starting
with 4 cards), using a chain of table look-ups, as discussed in the
2+2 thread.
Note also that smaller sets of cards can be subsumed into the large
tables, using a rank of 0000 as a "don't care" condition. For example,
all flush hands of 5, 6, or 7 cards are contained in the same table.
Sorry if this is vague and unintelligible (I'm not fully coffeed yet).
I have some Python code that more clearly defines what I'm talking
about, which I might make available when it's finished. I'm sure
others are better equipped to optimize the hell out of the idea... :)
- Darse.
That's awesome, Ray. I'm experiencing awe. ;-)
Can we squeeze this some more by *first* thinking about the fastest
possible hash index functions, and then making it work for cards?
(Is there something faster than bit shifts and XOR)?
I'm thinking it might be advantageous to represent cards keeping the
rank and suit separated (4+2 bits), rather than having to unravel the
6-bit representation for integers 0-51. Now the unordered rank pattern
can be determined quickly with bit operations, (28 bits = 268 million
table entries), and the suit pattern determines the flush exceptions.
- Darse.
On 4-Jan-07, at 8:37 AM, Ray wrote:
> Actually in under 10 cycles per hand... ;-)
>
> High Card = 23294460
> Pair = 58627800
> Two Pair = 31433400
> Three of a Kind = 6461620
> Straight = 6180020
> Flush = 4047644
> Full House = 3473184
> Four of a Kind = 224848
> Straight Flush = 41584
> Total Hands = 133784560
>
> Validation seconds = 0.5780
> Total HighPrecision Clocks = 1141158660
> HighPrecision clocks per lookup = 8.529823
>
> BTW, I love what you are doing for the Poker Programs yourself Darse
> (Poki
> and Research)...
>
> Ray...
>
> -----Original Message-----
> From: pokersource@yahoogroups.com [mailto:pokersource@yahoogroups.com]
> On
> Behalf Of Darse Billings
> Sent: Thursday, January 04, 2007 9:23 AM
> To: pokersource@yahoogroups.com
> Subject: Re: [pokersource] 2+2 thread on super fast evaluators
>
>
> Quite some time ago, "Cactus Kev" created a webpage about his fast
> 5-card
> hand eval:
>
> http://www.suffecool.net/poker/evaluator.html
> <http://www.suffecool.net/poker/evaluator.html>
>
> It exploits the equivalence classes of poker hands, where there are
> only
> 7462 distinct hand values. His indexing function is primitive, but the
> potential for very fast table-based evaluators is clear. The
> bottleneck is
> now in computing the hash index, and the 2+2 thread offers some clever
> tricks to do that in under 50 cycles per hand.
>
> - Darse.
>
> On 3-Jan-07, at 8:28 PM, Michael Maurer wrote:
>
>> There is a fascinating thread on 2+2 about building the next
>> generation of poker hand evaluators. Several posters have reported
>> 7-card hand eval rates well over 100M hands per second. The approaches
>> use "a lot" of memory, but nothing you would notice on your desktop
>> box.
>>
>> The thread is here:
>> http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=al
>> l
>> <http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=a
>> ll>
>>
>> -Michael M
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
Actually in under 10 cycles per hand... ;-)
High Card = 23294460
Pair = 58627800
Two Pair = 31433400
Three of a Kind = 6461620
Straight = 6180020
Flush = 4047644
Full House = 3473184
Four of a Kind = 224848
Straight Flush = 41584
Total Hands = 133784560
Validation seconds = 0.5780
Total HighPrecision Clocks = 1141158660
HighPrecision clocks per lookup = 8.529823
BTW, I love what you are doing for the Poker Programs yourself Darse (Poki
and Research)...
Ray...
-----Original Message-----
From: pokersource@yahoogroups.com [mailto:pokersource@yahoogroups.com] On
Behalf Of Darse Billings
Sent: Thursday, January 04, 2007 9:23 AM
To: pokersource@yahoogroups.com
Subject: Re: [pokersource] 2+2 thread on super fast evaluators
Quite some time ago, "Cactus Kev" created a webpage about his fast 5-card
hand eval:
http://www.suffecool.net/poker/evaluator.html
<http://www.suffecool.net/poker/evaluator.html>
It exploits the equivalence classes of poker hands, where there are only
7462 distinct hand values. His indexing function is primitive, but the
potential for very fast table-based evaluators is clear. The bottleneck is
now in computing the hash index, and the 2+2 thread offers some clever
tricks to do that in under 50 cycles per hand.
- Darse.
On 3-Jan-07, at 8:28 PM, Michael Maurer wrote:
> There is a fascinating thread on 2+2 about building the next
> generation of poker hand evaluators. Several posters have reported
> 7-card hand eval rates well over 100M hands per second. The approaches
> use "a lot" of memory, but nothing you would notice on your desktop
> box.
>
> The thread is here:
> http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=al
> l
> <http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=a
> ll>
>
> -Michael M
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
Quite some time ago, "Cactus Kev" created a webpage about
his fast 5-card hand eval:
http://www.suffecool.net/poker/evaluator.html
It exploits the equivalence classes of poker hands, where
there are only 7462 distinct hand values. His indexing
function is primitive, but the potential for very fast
table-based evaluators is clear. The bottleneck is now
in computing the hash index, and the 2+2 thread offers
some clever tricks to do that in under 50 cycles per hand.
- Darse.
On 3-Jan-07, at 8:28 PM, Michael Maurer wrote:
> There is a fascinating thread on 2+2 about building the next
> generation of poker hand evaluators. Several posters have reported
> 7-card hand eval rates well over 100M hands per second. The
> approaches use "a lot" of memory, but nothing you would notice on your
> desktop box.
>
> The thread is here:
> http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=all
>
> -Michael M
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
There is a fascinating thread on 2+2 about building the next
generation of poker hand evaluators. Several posters have reported
7-card hand eval rates well over 100M hands per second. The
approaches use "a lot" of memory, but nothing you would notice on your
desktop box.
The thread is here:
http://forumserver.twoplustwo.com/showflat.php?Number=8648777&fpart=all
-Michael M
Well, now I finally know what does each packet mean, but I was unable
to determine how to send/receive the packets. I mean - how to
encode/decode the packets? Do I have to use TCP or UDP connection? I
think poker-network uses SOAP, am I right? Could you, please, send me
just an example of a communication string? I need something concrete
to start with... Thank you very much!
--- In pokersource@yahoogroups.com, Loic Dachary <loic@...> wrote:
>
> olixnet writes:
> > Hello, I've been searching the web for some specificanion of the
> > poker-network protocol, but I've found none. I would like to write my
>
> There is none.
>
> > own client and thus I need to know how to communicate with
server. I'm
> > not into C/C++ so the reading of the sources won't help me. I've also
> > tried pocket sniffing, but the communitation seems do be encoded (no
> > surprise). Please, tell me where to find some documentation on this.
> > Thank you
>
> If you could read python that would help. Check
> http://gna.org/projects/pokersource/ source tree. All file with packet
> in the name contains packets with some documentation. The 2D client
and the
> bots can be used as examples to figure out the protocol.
>
> Which language do you plan to use ?
>
> --
> +33 1 76 60 72 81 Loic Dachary mailto:loic@...
> http://gnu.org/loic/gpg.txt sip:loic@...
>
> _______________________________________________
> Pokersource-users mailing list
> Pokersource-users@...
> https://mail.gna.org/listinfo/pokersource-users
>
I'm planning to use (yes I know it's noobish) VB6.
olixnet writes:
> Hello, I've been searching the web for some specificanion of the
> poker-network protocol, but I've found none. I would like to write my
There is none.
> own client and thus I need to know how to communicate with server. I'm
> not into C/C++ so the reading of the sources won't help me. I've also
> tried pocket sniffing, but the communitation seems do be encoded (no
> surprise). Please, tell me where to find some documentation on this.
> Thank you
If you could read python that would help. Check
http://gna.org/projects/pokersource/ source tree. All file with packet
in the name contains packets with some documentation. The 2D client and the
bots can be used as examples to figure out the protocol.
Which language do you plan to use ?
--
+33 1 76 60 72 81 Loic Dachary mailto:loic@...http://gnu.org/loic/gpg.txt sip:loic@...
_______________________________________________
Pokersource-users mailing list
Pokersource-users@...https://mail.gna.org/listinfo/pokersource-users
Hello, I've been searching the web for some specificanion of the
poker-network protocol, but I've found none. I would like to write my
own client and thus I need to know how to communicate with server. I'm
not into C/C++ so the reading of the sources won't help me. I've also
tried pocket sniffing, but the communitation seems do be encoded (no
surprise). Please, tell me where to find some documentation on this.
Thank you