River buckets
Page 1 of 1

Author:  t_steu [ Sat Dec 14, 2019 2:41 am ]
Post subject:  River buckets

I'm trying to create 10,000 flop, turn, and river buckets (30,000 in total) by following the potential-aware imperfect recall paper ( ... aaai14.pdf)

First step is to create the abstraction for the river. I'm trying to use k means to cluster hands with similar equity(vs range of all hands). I've calculated and saved the equity as a double for all 1326 hands on all 2598960 5 card boards. I'm having trouble initializing 10,000 unique and non empty buckets. I tried initializing the buckets to existing values, but its looking like there may not even be enough. The paper on Libratus said that they had >1 million river buckets, so I'm feeling quite stupid right now. Do I have a major misunderstanding or is it likely a problem with my code? I'm pretty confident that my equities are correct.

I haven't checked how many unique equities there are on the river, just basing this off the speed that it was initializing

Author:  billybob69 [ Sat Dec 14, 2019 6:16 am ]
Post subject:  Re: River buckets

hey good luck with an answer

Author:  t_steu [ Thu Dec 19, 2019 5:28 pm ]
Post subject:  Re: River buckets

So river buckets aren't based on equity,

see viewtopic.php?f=25&t=2381&start=0

Author:  spears [ Fri Dec 20, 2019 7:01 am ]
Post subject:  Re: River buckets

I never had a lot of faith in this type of abstraction and I never went down that route, so can't comment knowledgeably. I just want to make you aware if you weren't already that recent efforts seem to be moving away from this type of abstraction as a complete solution. I recommend watching the DeepStack video and reading the DeepStack and Pluribus papers. There is some doubt about how good DeepStack actually is but I think there is merit in the limited depth / value function approach. IIRC Libratus used a lot of resources.

Author:  t_steu [ Fri Dec 20, 2019 2:40 pm ]
Post subject:  Re: River buckets

My current understanding is that Modicum used these sources for to make its buckets ... amas15.pdf ... aaai14.pdf ... 1&type=pdf
steps in this order:
paper 3: evaluating state space abstraction
cluster turn(earth movers distance over equity distribution on all rivers) and river (clustering histograms of equity vs 8 ranges on the river by using k means and euclidean distance)

paper 2: earth movers distance
bucket flops by clustering histograms of how likely they are to transition into bucket n on the turn (keeping same turn/river buckets as paper 3)

paper 1: hierarchical abstraction
cluster public flop boards (not including our hole cards) by clustering histograms of how likely flop board plus holecard transitions into bucket n on the flop(using the previously computed abstraction from paper 2)
I haven't gotten through how they then cluster public+holecards on the flop/turn/river and I may not be entirely correct on this part

I was under the impression that pluribus used the same buckets as modicum, but I could look into it

Author:  spears [ Fri Dec 20, 2019 5:04 pm ]
Post subject:  Re: River buckets

You may well be right, but my point was they seem to be moving away from this type of abstraction as a complete solution. In Pluribus the bucketed abstraction produced the relatively small blueprint solution which was used as a starting point for a more detailed local solution at run time. I commented on the resources Libratus used because you had commented on the number of buckets. So you don't have to worry about the huge number of buckets Libratus used if you use the Pluribus technique of a blueprint solution enhanced at runtime.

Thanks for mentioning Modicum. I didn't know about that.

Author:  t_steu [ Fri Dec 20, 2019 5:52 pm ]
Post subject:  Re: River buckets

Thanks for the responses,

I believe Modicum and Pluribus are very similar (weak blueprint strategy and realtime depth limited solving). I mentioned the number of buckets libratus used because I didn't understand how they were able to create >1m buckets on the river when there are <2,000 unique equities. I now have a better idea of how those papers work together. I'm actually interested in seeing if I can use lossy abstraction for a postflop solver to get an estimate ev values and then use depth limited solving to get the exploitability down. All of that in hopefully less time/resources that a traditional lossless approach would take.

Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group