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 313 forks source link

Why is "bet 25%" option not displayed in the decision tree? #146

Open gosoy opened 2 years ago

gosoy commented 2 years ago

image Under such configuration, the decision tree in River does not include bet 25% but only check and all in. Are there anything that I missed? I think there is some option about OOP bet 315. image

bupticybee commented 2 years ago

Would you take a look at #129 first? Does it solve your problem?

maosatgithub commented 2 years ago

It is related to the 0.67 "allin threshold" setting. If you set this to one, the 25% river bet will show up.

I will say though, that I would not expect that 0.67 setting to hit here already, as on the river the pot is 1260, and the 25% bet would be 315, which is only 32% of the remaining 985 stack. So I might have missunderstood what the 0.67 should be relating to, or there is indeed a bug.

maosatgithub commented 2 years ago

Would you take a look at #129 first? Does it solve your problem?

I believe that is unrelated to this one.

maosatgithub commented 2 years ago

The rule is implemented in GameTree.cpp:653 like this: if(amount + rule.get_commit(player) > rule.initial_effective_stack * rule.allin_threshold) .... Here initial_effective stack should be 985, and rule.get_commit(player) 630 Amount for 25% is 315, so we have 945 compared with 0.67*985=659.97, which is indeed greater. I think this is an awkard comparision. I would rather have expected to have the bet amount compared to threshold times the inital_effective_stack. Does anybody know from the documentation of other solvers how they are interpreting such a threshold?

maosatgithub commented 2 years ago

So, I searched a little bit, and saw explainations on a piosolver forum, that they do the same comparision, HOWEVER, there inital_effective_stack as far as I understand it, is the stack size at the beginning of the hand, not at the moment of the current betting. Thus I now believe, that the calculation in Rule.cpp:11 is wrong:

this->initial_effective_stack = stack - oop_commit;

Instead, oop_commit should be added to stack.

Then the allin threhold would be comparing the total amount the player is investing with that bet into the hand to the initial stack the hand was started with. In this example 630+315 > 0.67*(315+1300), thus 945 > 1082.05, which is false, so the 25% bet would be accepted.

gosoy commented 2 years ago

Thank you a lot for your explanation. I will try modifying the all in threshold option.

maosatgithub commented 2 years ago

So, I searched a little bit, and saw explainations on a piosolver forum, that they do the same comparision, HOWEVER, there inital_effective_stack as far as I understand it, is the stack size at the beginning of the hand, not at the moment of the current betting. Thus I now believe, that the calculation in Rule.cpp:11 is wrong:

this->initial_effective_stack = stack - oop_commit;

Instead, oop_commit should be added to stack.

There I had the wrong assumption, that "stack" would be the remaining stack at that street/betting. Instead, "stack" is already the fixed total, inital stack size. So inital_effective_stack should then be just set to stack, which in return means, it can be just eliminate if stack is used in the allin_threshold calculation:

if(amount + rule.get_commit(player) > rule.stack * rule.allin_threshold) ...

As inital_effective_stack is not used elsewhere, it could then be eliminated.

Now, my inital thought about the meaning of the threshold was a different one: I was thinking it would describe the proportion of the bet to the remaining stack at the time of betting. That rule would look like this:

if(amount > rule.initial_effective_stack * rule.allin_threshold) ...

Then having this initial_effective_stack value would make sense. Not sure, if the name makes sense, though...

If somebody has PioSolver, could you please check what's really being done there? In the example above, the threshold as I interpret the forum posts should be around 36% for the river bet, so a 35% bet should be seen, while a 37% should be converted to an all-in.

If instead it would behave like my inital thought was, the threshold should be at 52%, so a 51% bet should be in, and a 53% replaced by allin.

bupticybee commented 2 years ago

So, I searched a little bit, and saw explainations on a piosolver forum, that they do the same comparision, HOWEVER, there inital_effective_stack as far as I understand it, is the stack size at the beginning of the hand, not at the moment of the current betting. Thus I now believe, that the calculation in Rule.cpp:11 is wrong: this->initial_effective_stack = stack - oop_commit; Instead, oop_commit should be added to stack.

There I had the wrong assumption, that "stack" would be the remaining stack at that street/betting. Instead, "stack" is already the fixed total, inital stack size. So inital_effective_stack should then be just set to stack, which in return means, it can be just eliminate if stack is used in the allin_threshold calculation:

if(amount + rule.get_commit(player) > rule.stack * rule.allin_threshold) ...

As inital_effective_stack is not used elsewhere, it could then be eliminated.

Now, my inital thought about the meaning of the threshold was a different one: I was thinking it would describe the proportion of the bet to the remaining stack at the time of betting. That rule would look like this:

if(amount > rule.initial_effective_stack * rule.allin_threshold) ...

Then having this initial_effective_stack value would make sense. Not sure, if the name makes sense, though...

If somebody has PioSolver, could you please check what's really being done there? In the example above, the threshold as I interpret the forum posts should be around 36% for the river bet, so a 35% bet should be seen, while a 37% should be converted to an all-in.

If instead it would behave like my inital thought was, the threshold should be at 52%, so a 51% bet should be in, and a 53% replaced by allin.

Hi @maosatgithub I'd like to thank your effort into this project. I'd be very glad if you could join this project to maintain or solve bugs or anyway you see fit. Like to know what's your thought.

As for the problem itself, I think I have promised to look into similar issue at least 10 times, but I never got the time sadly. Seems time is a very rare resource since I graduate.

maosatgithub commented 2 years ago

Hi @maosatgithub I'd like to thank your effort into this project. I'd be very glad if you could join this project to maintain or solve bugs or anyway you see fit. Like to know what's your thought.

Hi @bupticybee , thanks for the offer, I feel honored by it.

I am somewhat uncertain about the time I am myself able to spend consistently here. E.g., you might have noticed that I was away quite a while in summer. I certainly will try to help with bugfixes were I see an impact and a way to adress it, but I am uncertain if I should get deeper involved.

So I will think about it first, and then get back to you.

bupticybee commented 2 years ago

Hi @maosatgithub I'd like to thank your effort into this project. I'd be very glad if you could join this project to maintain or solve bugs or anyway you see fit. Like to know what's your thought.

Hi @bupticybee , thanks for the offer, I feel honored by it.

I am somewhat uncertain about the time I am myself able to spend consistently here. E.g., you might have noticed that I was away quite a while in summer. I certainly will try to help with bugfixes were I see an impact and a way to adress it, but I am uncertain if I should get deeper involved.

So I will think about it first, and then get back to you.

That's quite allright, I myself cannot ensure I have all the time I need, 100% understand how you feel.