New Stats unavailable to HUD

[andyco]

kraada, pasita,
thanx, both, for the quick responses.

pasita - yes. that is what i'm trying to do; your suggestion is logically the same.
This does work, however, it's still a less clean method of implementation.
I was trying to use an intermediate placeholder (id_hc_led_group) to calculate & hold an integer "id" of which holecard grouping
each hand fell into. My intention was to avoid this lookup & calculation in each subsequent cnt_ column generation (cnt_hc_grp_led_1,_2 ..._6, _9)
I've noticed that PT3 and the HUD slow down drastically with some of the customizations i've done. And because i'm not
fully confident i know which specific algorithms or customizations are causing the sluggishness, i may be over doing the attempt to
reduce computational steps (with extra size to the database).

Interestingly, you can do this sort of two-step algorithm if you do it in Variables(not columns). However, it tends to slow the hud/pt3 down and I'd
hoped by doing the calculation once (in Columns, at the lowest level), storing and reusing that answer would limit the # of computations (and time PT3 takes)...

Kraada - when you say:

Columns cannot be referenced effectively in other columns for addition the way you want to do it

Is this issue limited to only "Addition" (SUMming) or any use of Column data within an expression for any other columns (for HUD/cache Stats)?
or is the issue more specifically that i'm trying to store the intermediate data into a HTTPS column which changes each hand?
or something else?
Is there any documentation or discussion about the how/why/what of this?
I really would like to understand the mechanism or "rule" i'm breaking so that i can avoid it (and avoid wasting your guys' time ;-))

[pasita]

I've noticed that PT3 and the HUD slow down drastically with some of the customizations i've done. And because i'm not
fully confident i know which specific algorithms or customizations are causing the sluggishness, i may be over doing the attempt to
reduce computational steps (with extra size to the database).

I have a ton of custom stats in my HUD. A shitton, to be exact. I don't notice any real decrease in performance unless I have a stat in HUD referencing id_x_hand_strength. If I have two such stats, HUD is useless.

So I'm guessing trying to optimise algorithm efficiency might be overdoing it. Mind you that's still a guess.

[kraada]

Any stats referencing the holdem_hand_player_combinations table are going to be massively slower - this is a known issue that is quite complex to correct so I don't currently have an estimate for potential fix time at this point.

What you can't do is use one column as a variable.

If you build column_a with some definition and you want to build column_b that refers to column_a's value, that won't work. I'm really surprised you got anything to work honestly, using variables or not. Were you actually seeing valid data at any point?

[andyco]

Thanx for the replies.

Off the top of my head, most (all?) of the custom stats i can remember being slow, had to do w/ the manipulation of
individual hand/card data & thus mainly within HPPC arena. so, that helps a bunch to know that this sluggishness is known
and the specific impact zone.

The Stat is was attempting works properly now, removing the column - column references in the expressions.

I'd been doing most of my custom coding w/ variables (because i didn't want to commit anything to the database
until i was finished & certain i'd use the stat). I recently started moving stuff back down into Columns trying to be more
efficient (vs. sluggishness). I guess i'll move back to the "Variable space" for these type of calculations...

to be honest, Kraada, i'm not specifically sure whether the "variable version" of this algorithm produces the correct results.
I know the stat is available to the HUD & doesn't crash anything when i load it. It was producing a 0% as the result, (which
would be accurate until i reached a volume of hands -- which i hadn't done).
Now that i understand the limitation -- I don't think i was seeing anything that you wouldn't have expected. I'll let you know
if that changes.

thanx again.

[kraada]

You could use that stat in a custom report and use it on yourself (where you presumably have the most data) to see if it's working right. But I wouldn't be surprised to find it not working at all.

Either way do keep me posted.