Poker-AI.org http://poker-ai.org/phpbb/ |
|
Bucketing http://poker-ai.org/phpbb/viewtopic.php?f=24&t=2534 |
Page 1 of 1 |
Author: | cantina [ Sun Jul 21, 2013 2:43 pm ] |
Post subject: | Bucketing |
Thought: Why not cluster statistical metrics of the ahead/tied/behind histograms for each round? For example, from the flop, we roll out each turn, creating three histograms versus all op pockets. Then we calculate something like Skewness and Kurtosis for each histogram, giving us an idea of how the data within those histograms is distributed (stored in just 6 variables). We do the same for each river too. Including the current, normalized flop ahead/tied/behind, that's a total of 15 variables per hand from the flop, which describes the entire distribution of hands at each round, instead of just the hand strength on the river like with KHE and KHO. Code: for each turn ...
{ for each op_pocket ... { if (myev > opev) ahead_count += 1; ... } ahead_histogram[(ahead_count / total) * size] += 1; ... } a_kurtosis = kurtosis(ahead_histogram); a_ skewness = skewness(ahead_histogram); ... |
Author: | Hipp [ Mon Jul 22, 2013 12:25 pm ] |
Post subject: | Re: Bucketing |
Maybe it would be a good idea. But I don't get it, how you want do it for the flop? For turn it is clear: you check win/lose rate for river, and put it into histogram. But what exactly you want do on a flop? Histogram of histograms? |
Author: | cantina [ Fri Jul 26, 2013 2:21 am ] |
Post subject: | Re: Bucketing |
The above pseudo-code is for a single flop board, when calculating the turn. |
Author: | proud2bBot [ Tue Sep 17, 2013 1:10 pm ] |
Post subject: | Re: Bucketing |
The idea of breaking down distributions by the 2 measures sounds pretty smart. I could imagine we probably would need to use a modified distance measure for the clustering (maybe euclidean distance is not optimal), but the use of kurtosis and skewness seems like a pretty good method to abstract enough without losing the relevant information (shape of the distribution). Did you do some clustering with it? |
Author: | cantina [ Wed Sep 18, 2013 2:49 am ] |
Post subject: | Re: Bucketing |
I used Weka and tried a number of different clustering algos available through their package. I crunched small test EQs with 200m iterations each. Xmeans performed the best. They only offered a couple generic distance metrics, though. But, I dunno if anything special is needed, since we're just comparing similar metrics, not histograms. I think the neo poker guys did something like this for their HUL bot that won the 2013 ACPC. The above metrics reduced the number of flop boards from about 22k to 2.2k, just by removing duplicates, no clustering. They probably reduced the game size significantly in this fashion while retaining statistical relevance to the real, unabstracted game. |
Author: | Hipp [ Sun Sep 22, 2013 5:21 am ] |
Post subject: | Re: Bucketing |
There is only 1755 different flop boards. I don't know how you get 22k ? |
Author: | nemesis17 [ Sun Sep 22, 2013 10:18 am ] |
Post subject: | Re: Bucketing |
Hipp wrote: There is only 1755 different flop boards. I don't know how you get 22k ? There are 22100 = C(52,3) distinct flops and 1755 isomorphic flops. |
Author: | cantina [ Sun Sep 22, 2013 8:11 pm ] |
Post subject: | Re: Bucketing |
For whatever reason the stats method I used reduced it to ~ 2.2k. So, maybe it's not as efficient as it could be, or maybe I have bugs? I imagine the neo poker guys didn't use board texture at all, but performed stat analysis on all possible hands (and their histories). |
Author: | cantina [ Sun Sep 29, 2013 4:42 am ] |
Post subject: | Re: Bucketing |
Another idea, along the same lines... In the example above, we project forward from the flop, determining the possible win/tie/loss distribution on the turn/river. However, the problem with using LUTs, from the river we can't determine how our hand evolved to it's current state. For example, if the flop came Ac As Ad, then 2s on the turn and 3d on the river, it would be the same river board but a strategically different hand had we flopped As 2s 3d, then turned/rivered Ac Ad. To deal with this (while maintaining the same sized river LUT), we can project backwards, looking at the possible distributions that lead to our current river hand. So, at any given round, we're projecting forwards and backwards in time, in the same histogramatical fashion mentioned above. We can then perform stat descriptives on the histograms and cluster these hands into buckets that engender some sense of the complete game. From the river, I have about 47 attributes per hand -- a big clustering problem, but not infeasible. That's about 2.5 billion pieces of data. |
Author: | somehomelessguy [ Mon Sep 30, 2013 12:18 am ] |
Post subject: | Re: Bucketing |
Nasher wrote: Another idea, along the same lines... In the example above, we project forward from the flop, determining the possible win/tie/loss distribution on the turn/river. However, the problem with using LUTs, from the river we can't determine how our hand evolved to it's current state. For example, if the flop came Ac As Ad, then 2s on the turn and 3d on the river, it would be the same river board but a strategically different hand had we flopped As 2s 3d, then turned/rivered Ac Ad. To deal with this (while maintaining the same sized river LUT), we can project backwards, looking at the possible distributions that lead to our current river hand. So, at any given round, we're projecting forwards and backwards in time, in the same hisogramatical fashion mentioned above. We can then perform stat descriptives on the histograms and cluster these hands into buckets that engender some sense of the complete game. From the river, I have about 47 attributes per hand -- a big clustering problem, but not infeasible. That's about 2.5 billion pieces of data. i haven't entirely figured out what you're doing, but how is this different from recalling our buckets on previous streets? |
Author: | cantina [ Mon Sep 30, 2013 12:51 am ] |
Post subject: | Re: Bucketing |
It's not different per se, in function, and that's the point. It's different because you don't have to store the previous buckets in memory, but you're still able to connect them strategically. It's a bit like the best of both worlds (perfect and imperfect recall). |
Page 1 of 1 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |