Custom HUD stats preflop raise size

[Lakestone]

Actually I don't quite understand all of the things you wrote.
First off, its tourney_holdem_blinds.amt_bb not tourney_blinds.amt_bb - correct? And what exactly is that? Why are we doing the amount of blinds divided by that variable? I tried returning tourney_holdem_blinds.amt_bb only and got a huge SQL error.

Is there a page where I can read more in depth about the database fields?

[kraada]

You'll need the rebuild cache option to force a complete rebuild if the column exists and the description is just changed. And you're correct it's tourney_holdem_blinds - I was looking at the PT4 schema. You can find the full list of database elements available to you here.

[Lakestone]

I love this program, and I love the support you guys offer. I can't wait to buy PT4 :heart:

Cheers

[Lakestone]

I finished my statistics for the SB with 10bb, to confirm that the stats are being displayed correctly, I included all possibilities so that them all together would add up to 100%.

This is what I got...
[ img ]

I would appreciate if a mod could take a quick look at my columns and spot the mistake(s):

[ img ]
[ img ]

The statistics definition is(theCol / 10bb_Opp)*100 and the format is /%.2f.

[kraada]

BETWEEN includes the endpoints - so 1 is between 0 and 1 and between 1 and 2 - you must have a couple of cases exactly on your endpoints which are being double counted.

[Lakestone]

BETWEEN includes the endpoints - so 1 is between 0 and 1 and between 1 and 2 - you must have a couple of cases exactly on your endpoints which are being double counted.

Sorry I don't understand what you mean by 1 is between 0 and 1 and between 1 and 2. Could you perhaps write a small bit of code to illustrate it?

[kraada]

I mean that is how "between" works in PostgreSQL.

You have two stats:

sum(if[a between 0 and 1, 1, 0])
and
sum(if[a between 1 and 2, 1, 0])

If we have a hand where a = 1, then this hand gets counted twice. Once because 1 is between 0 and 1 (in PostgreSQL terms) - so it counts for the first row, and once because 1 is between 1 and 2 (in PostgreSQL terms) - so it counts for the second row.

The way to think about it is:

X BETWEEN Y and Z is true if and only if X >= Y and X <= Z.

[Lakestone]

I mean that is how "between" works in PostgreSQL.

You have two stats:

sum(if[a between 0 and 1, 1, 0])
and
sum(if[a between 1 and 2, 1, 0])

If we have a hand where a = 1, then this hand gets counted twice. Once because 1 is between 0 and 1 (in PostgreSQL terms) - so it counts for the first row, and once because 1 is between 1 and 2 (in PostgreSQL terms) - so it counts for the second row.

The way to think about it is:

X BETWEEN Y and Z is true if and only if X >= Y and X <= Z.

I don't see why it would count twice since I only have one BETWEEN per query. I'm still not sure how you advice me to structure it, but I tried following instead:
if[tourney_holdem_hand_summary.amt_p_effective_stack >= (tourney_holdem_blinds.amt_bb * 9) AND tourney_holdem_hand_summary.amt_p_effective_stack <= (tourney_holdem_blinds.amt_bb * 11)]
This got it "down" to 106% in total.

Close yet far :(

[kraada]

A player can both limp and fold - that would count as one limp and one fold and thus lead to results > 100%. That is the most likely cause that I see here for the results that you've got.

[Lakestone]

A player can both limp and fold - that would count as one limp and one fold and thus lead to results > 100%. That is the most likely cause that I see here for the results that you've got.

So in Fold, having the if statement flg_p_open = false should do it:?: Nothing changed for me though. Funny thing is, I tried creating a new database and added hands that I've myself only recently and I got 100% exactly (about 10 000 hands). So I guess my columns were fine, but a bigger database full of hands that you only observed can skew the numbers significantly.

Thanks you