Division by zero

[skyd1v3r]

Hello,

as you know custom stats might evaluate to a division by zero. How are these handeled when the user did not mind checking the divisor? SQL would clearly report an error. PT3 might catch that error, yet it would need to fill the gap. Can it be that these spots are simply let empty in the table? Or is there some default like 0 or 1 set in wherever there can no quotient be calculated?

I am curious since after adding some new custom stats 70% of my recorded players simply disappeared from public.holdem_cache, public.player and all of PT3. Right now I am reimporting all my hands (duh) into a new DB.

Thanks

[WhiteRider]

Division by zero in custom stats is handled by PT3 - it should show N/A for those stats where the opportunities are zero.
There may be complications if your stat's value expression isn't roughly of the form (x/y)*100, but it shouldn't "fail" either way.
If you have an expression which gives you problems please let us know what it is and we'll investigate.

[skyd1v3r]

I´ll try to track it down, as right now I cannot name the stat making the trouble.

(also it´s just a guess that it ever relies on the stat. I have created some custom tables withhin the PTs-database, that could also be the problem... )

Yet I´ll try your way of notation. I always used (100*x)/y to avoid trunctuation by the inprecise floor-division:
In valid SQL, (4/5)*100 is 0*100 = 0. while (100*4)/5 is 400/5 = 80.

Does the "format expression" field on in the second tab make any difference? As I hardly understand what the heck /%.2f means, I just duplicate without altering that line, unless the actual query is copied into that field. (like with $/Hand)

What makes me curious is that I have seen code explicitly stating the string to display when it fails to evaluate: Something like (IF...,sum(...), 'N/A'), mostly used in custom reports.

Thanks

[WhiteRider]

You may be right about (x/y)*100 in postgres in general, but it works in PT3 - I'm not a postgres expert but I think that is only a problem if x and y are integers: either way it works OK in PT3 so you don't need to worry about that.

Yes, Format Expression makes a difference - this defines how the stat's value will be displayed in reports and the HUD.
"/%.2f" means a float (decimal number) formatted to 2 decimal places. If you want it to 1 dp use /%.1f instead, for instance.
You can also use format_number or the other options available when you click Insert and view the Functions tab.

Stats/reports with (IF...,sum(...), 'N/A') are probably old - we did have a problem with divide by zero errors a long time ago but that was fixed.