search

bupticybee / TexasSolver

🚀 A very efficient Texas Holdem GTO solver :spades::hearts::clubs::diamonds:
https://bupticybee.github.io/texassolver_page
GNU Affero General Public License v3.0
1.8k stars 312 forks source link

Game Tree building, minimum raise sizes not implemented? #107

Open maosatgithub opened 2 years ago

maosatgithub commented 2 years ago

In no-limit poker there is usual a lower limit to raises, that the raise increase must be at least the size of the last increase (or inital bet). I found that the tree can build with e.g. a raise of total 6 on a bet of 5, which would not be allowed in most poker games.

(I added an example in the comments below)

maosatgithub commented 2 years ago

PS: I can look into fixing this and #105 myself, once you make a design decision how they should be implemented.

maosatgithub commented 2 years ago

Ok, while I made a mistake in that the issue is not showing up in the #105 example, it is still there:

output_parameters-no-lower-raise-limit-bug.txt

image

bupticybee commented 2 years ago

In no-limit poker there is usual a lower limit to raises, that the raise increase must be at least the size of the last increase (or inital bet). I found that the tree can build with e.g. a raise of total 6 on a bet of 5, which would not be allowed in most poker games.

(I added an example in the comments below)

Actually I implemented the lower bound logic, please check the code here:

https://github.com/bupticybee/TexasSolver/blob/master/src/GameTree.cpp#L689

However I have to confess that I don't play holdem a lot so It could be implement wrong, as you suggest in your comment. There are actually other issues on this matter.

When I first code the tree construction part, I tried to make it the same as piosolver, and soon find out that piosolver's bet sizes are very confusing to me. I tried my best to make them the same, however I do not underestand the meaning of 3x or 50% pot, there are different ways of definine things, and each software seems to invent a way to define it themself.

So in conclusion, the whole tree construction part is a mess, I actually excepts bugs to occur here. Feel free to modify it , I think it's very unlikely you could do any worse than I did.

maosatgithub commented 2 years ago

Actually I implemented the lower bound logic, please check the code here: https://github.com/bupticybee/TexasSolver/blob/master/src/GameTree.cpp#L689

I think player and next_player are interchanged, so the gap is negative and the check always true.

So in conclusion, the whole tree construction part is a mess, I actually excepts bugs to occur here. Feel free to modify it , I think it's very unlikely you could do any worse than I did.

I'll have a further look.

bupticybee commented 2 years ago

Oh, such a bug... It would cause prblems for sure.

SynAckFin commented 2 years ago

The problem is with this line: float gap = rule.get_commit(player) - rule.get_commit(next_player); Since next_player either raised, bet or checked gap will either be negative or zero. The line needs to change to: float gap = rule.get_commit(next_player) - rule.get_commit(player);

EDIT: I see @maosatgithub already diagnosed this problem earlier.

bupticybee commented 2 years ago

The problem is with this line: float gap = rule.get_commit(player) - rule.get_commit(next_player); Since next_player either raised, bet or checked gap will either be negative or zero. The line needs to change to: float gap = rule.get_commit(next_player) - rule.get_commit(player);

EDIT: I see @maosatgithub already diagnosed this problem earlier.

I see. Just return from a holiday trip, will start to view all the issues.