How do you round spec values in Empower 3 for a custom field?
I have an LOD value for Amount of 0.01 for one of my components and I want to create a Custom Field which will return 0 if the amount if below 0.01 or return the Amount if greater than or equal to 0.01. I know I could code a CF like LT(ROUND(Amount,-2),0.01)*0+GTE(ROUND(Amount,-2),0.01)*Amount.
But I have seen this done a second way by adding an extra digit to the next decimal place so for example if your LOD was 0.02 then you could start the first argument by LT(Amount,0.015)*0 BUT I would have thought for the 0.01 value you put LT(Amount, 0.005)*0 but this isn't what I have seen- it was coded as LT(Amount,0.0095)*0.
I don't understand how 0.0095 is the minimum value that would round to 0.01, surely its 0.005 which to 2 decimal places is 0.01? Unless im missing something here.
Any insights? Thanks.
But I have seen this done a second way by adding an extra digit to the next decimal place so for example if your LOD was 0.02 then you could start the first argument by LT(Amount,0.015)*0 BUT I would have thought for the 0.01 value you put LT(Amount, 0.005)*0 but this isn't what I have seen- it was coded as LT(Amount,0.0095)*0.
I don't understand how 0.0095 is the minimum value that would round to 0.01, surely its 0.005 which to 2 decimal places is 0.01? Unless im missing something here.
Any insights? Thanks.
0
Answers
-
I would use a "replace" function ("<LOQ" or "<0.01" instead of 0). Some people think that it's a good idea to report at a limit if a value can arguably be rounded to said value. I disagree with this thinking, but it is the source of these less than intuitive values that show up in the CF examples you cite.0
-
Empower follows standard rounding so I don't know where the 0.0095 would come from in that other than as a mistake or their criteria was really 0.010 with the extra sig fig. I prefer the approach that Dan_Ramlose states as well with a "<LOQ" value (I suppose I usually do the BPQL translation of -60009 in Empower rather than a text replacement) reported rather than a flat out 0. Using "<LOQ" or "BPQL" and the CConst field for the LOQ value also gives you the flexibility/robustness of being able to use one field vs many in case some other method/peak has a different LOQ value.
In the end, a function with "LT(ROUND(Amount,-2),0.01)" vs "LT(Amount,0.005)" end up with the same answer. Admin's choice on this one. I think that for less savvy people, seeing the round function is a little more plain as it translates more directly to what they might think of when doing the math in their in their head vs the underlying understanding that 0.005 and higher will round to 0.01 for the purpose of the LT test.0 -
Worth looking at the use of text strings as mentioned above in CF formula
-50000 = no text, -60000=ND,-60001=N.D,-60002=Not Detected,-60003=N/D, -60004= NA, -60005= Not Found, -60006= Below Detection Limit , -60007= BDL, -60008 = Below peak quantitation limit , -60009 = BPQL
0 -
Thanks for the replies guys. Yes, I figure 0.0095 must be an error as the spec is 0.01 so 0.005 would suffice for that. The only issue I have with ROUND is I would only use it on the final part of the calculation. So for example a CF for percent impurity like Area/CCalRef1[Area]*100 would give you Percent_Imp but your method states that when Percent Impurity is Less than 0.02 its Below LOD and if its greater than or equal to 0.02 its reported. In that case a CF Like my first post is appropriate. But I wouldn't then use that CF in a further CF, ie if ROUND is used twice on the same parameter, you are double rounding which would lead to some inaccuracy.
When final specs change often, I find it handy to use the CConst fields to reflect this. example: LT(ROUND(Per_Imp,-2),CConst1)*1...etc. That way you can just update CConst with the latest spec.
0 -
While I agree with you on use of CConst (and the utility of added CFs to reflect the results of comparisons to CConst), I can't help feeling that once I figure out more about using the Impurities tab in the PM, that will be the easier way to go.Empower2018 said:Thanks for the replies guys. Yes, I figure 0.0095 must be an error as the spec is 0.01 so 0.005 would suffice for that. The only issue I have with ROUND is I would only use it on the final part of the calculation. So for example a CF for percent impurity like Area/CCalRef1[Area]*100 would give you Percent_Imp but your method states that when Percent Impurity is Less than 0.02 its Below LOD and if its greater than or equal to 0.02 its reported. In that case a CF Like my first post is appropriate. But I wouldn't then use that CF in a further CF, ie if ROUND is used twice on the same parameter, you are double rounding which would lead to some inaccuracy.
When final specs change often, I find it handy to use the CConst fields to reflect this. example: LT(ROUND(Per_Imp,-2),CConst1)*1...etc. That way you can just update CConst with the latest spec.0 -
Hi Dan, I have tried to use the Impurity tab several times and although it seems a great concept on paper, the final event just doesn't translate to a user-friendly experience, in my view. Looking at the report method is so confusing and its hard to know whats going on. I stick to the easier method of a custom field which reports percent impurity or just <LOD etc.0
-
Agreed. That is why I created my own approach as well. The results generated by using the impurity tab are not what I would call in an easily human readable format.Empower2018 said:... the final event just doesn't translate to a user-friendly experience, in my view. Looking at the report method is so confusing and its hard to know whats going on.
0
