I'm considering coding my own solver. Has anyone done this? I am wondering if there are any good and free resources I could use as a starting point. I know how to code and am familiar with many types of mathematical and machine learning models so it's more a matter of how to set up the problem conceptually. I found one video pack which walks you through coding a solver in python but it's 20 hours and costs $100 so I'm just wondering if anyone knows of something less detailed and/or cheaper - more of like an outline as opposed to complete instructions. Thanks!

Good luck with your bot.

LOL. I see why you might say that. But no, I'm not interested in making a bot, just want to understand how these things work under the hood, be able to tweak them in the way I want, and learn more about GTO and other strategies.

Did the Libratus team publish their methods?

I haven’t studied poker in the context at all. Not sure which methods are effective or popular. The first approach that comes to mind is to establish an initial strategy for one player and iteratively calculate the maximally exploitative counter strategy until convergence is reached. However I have no idea how many iterations it would take to reach convergence or if strategies would necessarily converge to Nash at all. Also bet sizings would have to be provided.

In fact there is a youtube video on Libratus' methods:

https://www.youtube.com/watch?v=2dX0lwaQRX0

Fun stuff! I believe most applications still use counterfactual regret minimisation or its variants with pio being the only unique one and using some form of gradient descent. So that would be the first thing to look over and learn. There are plenty of papers that have been published on CFR and each are a good read. Try also the poker-ai forums, smart people over there that can point you in the right direction.

I made reasonable progress on this project some time ago and then abandoned it for various reasons. So I wish you the best of luck!

I believe the University of Alberta has freely avaialble academic papers but I haven't looked into it in awhile. Just starting back up actually, but more on the equity calculator first to practice coding and build up to a solver potentially. I would be interested if you find something and posted pack or pm'ed me. Good luck!

There are fundamentally two parts: 1) the tree and EV calculation 2) algorithm to adjust strategies.

The first thing you need for a solver is to build in RAM a tree with strategies and be able to calculate EV and Max exploit in all nodes for all actions. You need to make it really memory efficient and fast if you want speed similar to commercial solvers. (Hint: don't use double-precision for storage

There are many cool challenges involved in the tree building part.

Once you have that reasonably fast the fun part begins. You can start with some basic strategy adjustment algorithm like CFR+. It's relatively easy to implement it by following the papers.

Thank you!

Thanks for the thoughts all, especially @juggler97531.

I'm working on a solver currently and I can't make the tree size small enough to fit in memory once I include the regret sums and strategy sums. My tree only consists of the possible action sequences (no chance nodes), so each decision node has a separate regret sum and strategy sum for each possible hole card combination and board runout. With two bet sizes per street and one raise size per street, I'm getting 1218 decision nodes, 1007 of which are on the river. So that means I need this many floats approximately:

1007 river decision nodes * 2.5 actions on average per node * 1326 hole card combinations * 47 turn cards * 46 river cards * 2 floats (one for regret sum and one for strategy sum) = 13 billion floats

1 float = 4 bytes so that's 52 gigs of RAM.

Even if I represented floats as 2 bytes I'm still looking at 26 gigs of RAM.

Somehow piosolver only needs 6 gigs of RAM for the same tree.

Any advice?

The best I can figure is that the probability that each action is taken in the strategy is represented with 10 bits (three significant figures, from 0.000 to 1.000) and that you don't store regret sums and strategy sums in RAM but on disk, meaning you're compressing and decompressing theses values on the fly for CFR.

we work on one. pm me than we can talk and see if we can help each other.

You probably don't compare exactly the same tree, but

- Yeah, CFR is memory consuming. If you keep only strategies then you only need 1 float per hand. In this case for 2.5 children you only need to remember 1.5 float.
- on the river there are considerably less than 1326 holecards
- there might be significantly less turns/rivers to consider (e.g. on a paired board)

HUSNG.com have a video pack from Will Tipton.

(not that I recommend husng.com , I bought other video I found it outdated. Their solver one helps you make a 32bit solver which I find funny considering its super ram consuming software. its not too expensive tho so might want to give it a shot)

Chill down guys. Making a bot is not about making the software itself but making it undetectable. So if a guy wants to make a solver, need to get info about it on 2+2 public forums its not too likely he can make a bot and stay undetected with that level of knowledge.