Poker-AI.org

Poker AI and Botting Discussion Forum
It is currently Mon Nov 13, 2023 12:36 pm

All times are UTC




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Omaha HS2 and Bucketing
PostPosted: Sat Apr 04, 2020 9:19 pm 
Offline
Veteran Member

Joined: Wed Mar 20, 2013 1:43 am
Posts: 267
After I finished my PLO hand evaluator I wanted to start creating buckets, but I realized that I miscalculated something and there are way more card combinations and isomorphic indexes than I thought.
Kevin Waugh's implementation gives me 19,569,128,722 river indexes for
Code:
   hand_indexer_t indexer;
   const uint8_t cards_per_round[2] = { 4, 5 };
   hand_indexer_init(2, cards_per_round, &indexer);

HS2 tables would take around 80GB as 4 byte floats and I would never be able to cluster so many points into buckets.
It must be possible somehow, because Monker Solver does support PLO.
Even if I cluster the boards first, I will still need the HS2. Am I still missing something or are those tables just that big? Anyone tried creating a PLO solution?


Top
 Profile  
 
PostPosted: Sun Apr 05, 2020 1:42 pm 
Offline
Veteran Member

Joined: Wed Mar 20, 2013 1:43 am
Posts: 267
So far I came up with 3 ideas:
1. Instead of storing the HS as a float I can use unsigned chars, it won't be as accurate but it will be much smapper. The logic is to assign an 8 bit char between 0 and 255 to a HS value between 0.0 and 1.0, so 0 = 0.0, 255 = 1.0, 122 = 0.5 etc.
2. I could write my own isomorphism algorithm, this could be more space efficient than K. Waugh's implementation because I could collapse hands that don't make flushes. However this is a pretty hard thing to do and I don't know how much space I would really save, especially since this would be my first time writing an algorithm like that.
3. Instead of using HS on the river, I can use some sort of absolute hand strength. For example 10 buckets for straights, 10 buckets for flushes etc. I think this will not be as effective as using HS2, but it would be much easier to compute, since I have to evaluate the hands anyway during the CFRM training.


Top
 Profile  
 
PostPosted: Sun Apr 19, 2020 11:44 pm 
Offline
Veteran Member

Joined: Wed Mar 20, 2013 1:43 am
Posts: 267
I went for the option of using unsigned chars instead of floats, it will mean a 20GB table but that will be ok.

Now I am facing another challenge: I want to write a parser that accepts pro poker tools syntax for omaha hands and returns a range of hands. Anyone tried to do something like that? Is any code available, c++ if possible?

Edit: I have found this Python library:
https://github.com/tredfern0/pptparser

Has anyone used it? My plan is probably to translate it to c++.


Top
 Profile  
 
PostPosted: Tue Apr 21, 2020 9:50 am 
Offline
Senior Member
User avatar

Joined: Sun Mar 10, 2013 10:31 am
Posts: 139
I think calculation of absolute hand stranght will be not so slow. and require zero LUTs.


Top
 Profile  
 
PostPosted: Sat Aug 21, 2021 5:16 pm 
Offline
New Member

Joined: Fri Mar 12, 2021 3:53 pm
Posts: 9
HontoNiBaka wrote:
So far I came up with 3 ideas:
1. Instead of storing the HS as a float I can use unsigned chars, it won't be as accurate but it will be much smapper. The logic is to assign an 8 bit char between 0 and 255 to a HS value between 0.0 and 1.0, so 0 = 0.0, 255 = 1.0, 122 = 0.5 etc.
2. I could write my own isomorphism algorithm, this could be more space efficient than K. Waugh's implementation because I could collapse hands that don't make flushes. However this is a pretty hard thing to do and I don't know how much space I would really save, especially since this would be my first time writing an algorithm like that.
3. Instead of using HS on the river, I can use some sort of absolute hand strength. For example 10 buckets for straights, 10 buckets for flushes etc. I think this will not be as effective as using HS2, but it would be much easier to compute, since I have to evaluate the hands anyway during the CFRM training.


monker does #2:

Omaha postflop
Omaha is too large to solve completely even when starting from the flop. MonkerSolver therefore reduces the game size by making the following concessions:

Before the river, only suits which has the potential to become flushes are considered. For example, these two hands are merged, even though they influence the opponents range slightly differently:

A♠K♠J♠5♠ 6♣5♣2♣7♣
A♠K♥J♥5♦ 6♣5♣2♣7♣
On the river, only suits with 3 or more cards on the board are considered. For example, consider these hands:

A♠K♠A♦K♦ 6♠5♠2♥7♥T♥
A♣K♣A♦K♦ 6♠5♠2♥7♥T♥
The above two hands are merged into the same bucket. They are however not strategically equivalent, since we are more likely to be up against a missed flush draw with the latter hand.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group