Bug in fold to SB steal stat?

[stevi3p]

I believe there may be a bug in the way PT calculates the % of times the BB folds to a steal from the SB (NB this isn't a custom stat - it's not in blue in my database). The numerator is:

cnt_p_BB_fold_to_SB=sum(if[substring(lookup_actions_p.action from 1 for 1)='F' AND
holdem_hand_player_statistics.position = 8 AND holdem_hand_player_detail.val_p_raise_aggressor_pos = 9 AND holdem_hand_player_statistics.flg_blind_def_opp,1,0])

which seems fine.

But the denominator is:

cnt_p_BB_fold_to_SB_opp=sum(if[holdem_hand_player_statistics.position = 8 AND holdem_hand_player_detail.val_p_raise_aggressor_pos = 9 AND holdem_hand_player_statistics.flg_blind_def_opp,1,0])

I think this is wrong, because if the BB 3bets the SB then it won't show up as giving the BB an opportunity to fold to a SB steal, since, as I understand it val_p_raise_aggressor_pos will change to 8 (the position of the BB) since he becomes the last aggressor - (based on viewtopic.php?f=18&t=18895&p=89871&hilit=val_p_raise_aggressor_pos#p89871). This can lead to extremely biased results, since the BB will 3bet the SB pretty often in position. For a typical TAG, this could be 10%, so might change the %fold from, roughly, 65% to 55%. This makes a huge difference to the EV of stealing.

Grateful if you could let me know if my reasoning is correct. If it is, could this stat be fixed asap, as it is an important one. I don't see anyway of fixing it immediately, since the position of the initial raiser isn't stored currently (I believe). This makes it really important that PT3 does store the position of the original raiser (and any 3bettors, as I've asked for previously).

More generally, the way stats gets prioritised seems rather haphazard. To pick one random example, we have a stat called based on "Total number of times a player called made a bet or raise on the flop and won the hand at showdown." which seems not much use for a variety of reasons (e.g., combining a bet and a raise in the same stat is really misleading since they generally mean very different things / the gap between showdown and flop is too large / no info re: position), yet PT3 doesn't store the initial raiser preflop which seems far more important. PT3 would be better off basing more stats on preflop activity which is more useful, since there is less other information - re: board texture / betting patterns etc to go on and so the hud stats become much more impoortant to my decision making. (IMO.)

On an entirely separate matter, could you make the custom stats less fussy re: spacing etc? I often have to include random spaces to make stats work, and a stat which had worked for all previous versions suddenly stopped working. The reason? PT3 suddenly decided that I need to insert a space after a minus sign! (NB, it validated OK, just wouldn't work in Table Tracker.)

Cheers

Steve

[WhiteRider]

I believe there may be a bug in the way PT calculates the % of times the BB folds to a steal from the SB.
...
I think this is wrong, because if the BB 3bets the SB then it won't show up as giving the BB an opportunity to fold to a SB steal, since, as I understand it val_p_raise_aggressor_pos will change to 8 (the position of the BB) since he becomes the last aggressor...

This isn't the case - the raise-aggressor is never the active player, so if you are looking at this from the BB's point of view the raise-aggressor-position will never be 8, it will remain as 9 in this case.
Therefore the BB folds to SB stat is OK.

More generally, the way stats gets prioritised seems rather haphazard. To pick one random example, we have a stat called based on "Total number of times a player called made a bet or raise on the flop and won the hand at showdown." which seems not much use for a variety of reasons (e.g., combining a bet and a raise in the same stat is really misleading since they generally mean very different things / the gap between showdown and flop is too large / no info re: position), yet PT3 doesn't store the initial raiser preflop which seems far more important. PT3 would be better off basing more stats on preflop activity which is more useful, since there is less other information - re: board texture / betting patterns etc to go on and so the hud stats become much more impoortant to my decision making. (IMO.)

That stat that you quote is (IIRC) for the More Detail report which is based on what was shown in PT2, which is why it was created.
FWIW I agree about wanting more info about things like position of initial raisers and have made suggestions to the development team in the past. I'm still hoping this sort of thing will be added, but I don't know when.

On an entirely separate matter, could you make the custom stats less fussy re: spacing etc? I often have to include random spaces to make stats work, and a stat which had worked for all previous versions suddenly stopped working.

We're aware of this, and it will be made less fussy, but again I don't know when.

[stevi3p]

Thanks a lot for your reply - I hadn't realised that the agressor stat worked in this way.

On the other issue, I still feel there are way too many unnecessary stats, which just bloats my database, but I understand that you want to cover as many databases as possible. Could there be an option an option in future to delete the columns / stats that we don't want? Or is this just an absolute nightmare for your guys? One option is to relegate the lesser used stats to a custom stat.....

Thanks

Steve

[WhiteRider]

Most people say there should be more built-in stats...
I doubt that you will ever be able to delete any of the built-in stats - that would cause no end of problems.

[stevi3p]

You mean you can't do exactly what every single one of us wants all the time :o :D

I guess my suggestion is that many stats aren't built-in but are custom stats... For some of the more obscure stats, or groups of stats, I think you should give people the option of uploading them rather than automatically just putting them in the database. My database takes c.12 hours to do a full housekeeping run and it's probably only going to get worse over time.

Thanks

Steve

[kraada]

We have long term plans to cut out the need for the cache update entirely by keeping the cache up to date at the time of import. It will take a while before that feature will be available but once it is that should cut down housekeeping time by half.