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

minimum allowed raise size is 60% of pot size raise #129

Closed nbiresev closed 2 years ago

nbiresev commented 2 years ago

img As you can see in the screenshot, i have defined pot size = 5, bet size is 3. Raise sizes i defined 50, 75, 100, 150. When i click show results, i marked this part with red, you can see that raise sizes that it uses are 9, 11, 14, 20. Considering that pot size raise in this example is 3 * bet size + pot size = 14. So raise sizes 11, 14, and 20 are correct for 75, 100 and 150. But for 50% pot size raise it should be 50% of 14 = 7 and you have it 9. Why is this the case? to me it seems that it doesn't allow raise less than 60% pot size raise.

maosatgithub commented 2 years ago

No, your assumption is not correct. The basis for the calculation is the pot size after the bet would have been just called.

Lets write this as Pnew = Pinital +2B.

Which is here 5+2*3 = 11.

The total raise is then the inital bet size + the raise percentage times Pnew,

so Rtotal = B + x * (Pinital + 2B).

So 50% of 11 is 5.5, which gets rounded, and added to 3. So it is rounded to 6, and 3+6 is 9, which is used. And 75% of 11 is 8.25, which gets rounded, and added to 3. So it is rounded to 8, and 3+8 is 11, which is used. And 100% of 11 is 11, which added to 3. So it is 3+11 is 14, which is used. And 150% of 11 is 16.5, which gets rounded, and added to 3. So it is rounded to 17, and 3+17 is 20, which is used.

Thus I think this issue can be closed.

nbiresev commented 2 years ago

Thank you for explanations, i have missunderstood the % of pot size raise.

bupticybee commented 2 years ago

No, your assumption is not correct. The basis for the calculation is the pot size after the bet would have been just called.

Lets write this as Pnew = Pinital +2B.

Which is here 5+2*3 = 11.

The total raise is then the inital bet size + the raise percentage times Pnew,

so Rtotal = B + x * (Pinital + 2B).

So 50% of 11 is 5.5, which gets rounded, and added to 3. So it is rounded to 6, and 3+6 is 9, which is used. And 75% of 11 is 8.25, which gets rounded, and added to 3. So it is rounded to 8, and 3+8 is 11, which is used. And 100% of 11 is 11, which added to 3. So it is 3+11 is 14, which is used. And 150% of 11 is 16.5, which gets rounded, and added to 3. So it is rounded to 17, and 3+17 is 20, which is used.

Thus I think this issue can be closed.

I knew there is something wrong about the game tree construction algorithm, which probably cause the difference with piosolver. Now I'm a little bit confused how to modify the algorithm, can you give me some hint?

nbiresev commented 2 years ago

Regarding the raise sizes and reraise, your algorithm works fine i didn't see a difference (compared to gto+), it was me who understood it wrong. By comparing ranges with gto+ i notice difference in frequencies of ranges, especially the the thing that your solver likes to donk much more than gto+ where it happens with low frequency only on turn and river.

maosatgithub commented 2 years ago

Thus I think this issue can be closed.

I knew there is something wrong about the game tree construction algorithm, which probably cause the difference with piosolver. Now I'm a little bit confused how to modify the algorithm, can you give me some hint?

No, there is nothing wrong with the algorithm here. As I stated I think the issue can be closed, since the solver as implemented works as expected. There was just a false expectation on nbiresev's side how a fraction of the pot raise should be calculated, which he did confirm now.

bupticybee commented 2 years ago

Thus I think this issue can be closed.

I knew there is something wrong about the game tree construction algorithm, which probably cause the difference with piosolver. Now I'm a little bit confused how to modify the algorithm, can you give me some hint?

No, there is nothing wrong with the algorithm here. As I stated I think the issue can be closed, since the solver as implemented works as expected. There was just a false expectation on nbiresev's side how a fraction of the pot raise should be calculated, which he did confirm now.

Okay~ thanks very much for your time and effort!