Nested Boolean arguments within summary custom field
Apologies for the / symbol in above equation it should be straight line for "OR". Does the or symbol therefore include all the possible labels? I thought OR would only give the rsd of label C1 at label C1 and the rsd of label C2 at label C2 etc but it seems to include all of them. And why would the OR symbol not be included for the NEQ part? If this was changed to NEQ(Label,"C1")+NEQ(Label,"C2")..etc would this just add 2 to the previous calculation because you have 2 labels which will return a 1 for the NEQ arguments i.e. C5 and C6?
Is the & symbol needed for the NEQ section because you want any label that isnt C1 to C4 excluded? Im trying to understand nested arguments a bit better.
Comments
-
Hi ,
Wouldn't it be easier to use report summary functions (% RSD) with correct precision with data filtering C ?
0 -
I could do it that way but what if you needed the value for a further calculation? Thats why i was asking about the OR function. It seems the OR includes all the arguments within it.0
-
Ok , I only use OR (/) function in basic Boolean
Should text string -50000 be outside bracket perhaps ?
0 -
Does the or symbol therefore include all the possible labels? If you ignore the NEQ portion for now, the EQ(Label, “C1”)…etc. each return a 1 or 0 whether true or false. The OR then would say that if any are true, it reports the 1 and therefore the “area” is used in the field and it ultimately just returns C%.%..%RSD(1*Area) if any of the C# conditions match. This would then be why they all report the same value rather than individual values with respect to their label. If the label fails to match any of them, you get C%.%..%RSD(0*Area) result of 0. There is no distinction for the %RSD for just C1, C2, etc. within the result. By chance, if you do manually calculate it since you say you got the same value for all, does it report the %RSD of all 6 rather than just 4 (I imagine it should based on the overall resulting formula and the use of a Summarize Custom Fields in the sample set)?
I’m not quite clear on how to interpret the NEQ portion. It doesn’t really make a lot of sense to include that inside the %RSD function. The use of the & vs OR is also a bit odd to me. By using &, Empower should interpret it such that you get a 0 all the time as your label will never match all of them and the ultimate return from the formula is C%.%..%RSD(Area). If the & is switched to an OR, then matching any one of them would return a 0 and not matching any would return a -50000 or blank. If that is contained within the %RSD, I see it causing issues in consistency. For C2 with NEQs inside the %RSD, you’d get C%.%..%RSD(Area+0). For C5, you’d get C%.%..%RSD(0+-50000), not an outright blank space which would likely be the intention. Moving the NEQ test outside of the %RSD and changing them to ORs should result in C%.%..%RSD(Area) for C2 and simply -50000 for C5.
I thought OR would only give the rsd of label C1 at label C1 and the rsd of label C2 at label C2 etc but it seems to include all of them. And why would the OR symbol not be included for the NEQ part? I don’t see that happening when you simplify the overall results in the formula, as described above.
If this was changed to NEQ(Label,"C1")+NEQ(Label,"C2")..etc would this just add 2 to the previous calculation because you have 2 labels which will return a 1 for the NEQ arguments i.e. C5 and C6? Putting a + in…remember that this is calculated on a line-by-line basis. For C1, it does the calc…in the example you gave that goes through C4, that means three values of NEQ returning a 1 and one value of 0, not two values of 1. The same goes for C2 and so on. C5 and 6 don’t come into play within that. When it goes to calculate C5’s result, the %RSD part of the function would return a 0 and, if you make the change of moving the NEQ out of the %RSD, it should return a -50000 overall and report a blank.
0 -
Thanks for the reply, MJS.
When you say that the formula is calculated on a line by line basis, I thought summary custom fields take into account the whole sample set? So presuming you have the search order for the custom field set to summarize custom fields, when Empower encounters this line it then takes into account all labels and all lines of the sample set before storing results.
As for the NEQ part, I see what you mean about 3 arguments being 1 because at label C1, the other 3 parts return 1 but how would you move the NEQ argument "outside of the %RSD bracket"? Is it something like C%.%..%RSD((EQ(Label,"C1")/EQ(Label,"C2")/EQ(Label,"C3)/EQ(Label,"C4")*Area))+(NEQ(Label,"C1)|NEQ(Label,"C2")|NEQ(Label,"C3")|NEQ(Label,"C4"))*-1*50000?
I don't know why its set up this way either, its a copy of Neil Landers article from Inform 2019.
0 -
Water is the necessity of human life. Our body is made of 70 percent water. To stay healthy, we need to stay hydrated. We usually don’t give much thought to it. But There are different types of water around us. All types of drinking water have their own qualities and benefits.
As we know water is vital for our body and it’s the basic after oxygen for human life. It performs multiple actions in the human body to keep it healthy. Such as, increase energy, brain function, provides the body with different nutrients and minerals, helps in digestion, balance sodium in the body and so on. It might be colorless and tasteless but beats all the refreshing drink. No drink can take its place to keep you healthy and energized.
You probably thought that how come there are different types of drinking water? what is the healthiest water to drink? How do different types of drinking water vary when it comes to drinking? Water is simply water! Don’t get confused as we have listed 9 different types of water you can drink. Based on their composition, taste, origin, and benefits.
-1 -
It would seem to be taking into account the entire sample set, but that's then exactly why you are getting a single value for all rather than the incremental value you were trying to accomplish. I'd be interested if this could actually work that way, but I don't quite see how. The label in the formula would seem to be the root of it and so addressing the C% is what throws me off as even with the search order, it would go back through and see that C3 exists even though it is processing C2 at the time.
I've gone through a much more involved way of doing something like this where each group/bracket is it's own formula, then I have an enum field to specify which to report.
My workaround:
A bracket calc like: Area-C1..(Area), then Area-C2..(Area)
An enum field like: ENUM(EQ(Label, C1).... returning Bracket1 (fc), Bracket2 (fc), etc...I then report the ENUM field on the report to only show the correct/applicable result.0
