## Re: [limesurvey-developers] need opinion on cascading relevance logic

 Re: [limesurvey-developers] need opinion on cascading relevance logic From: Thibault Le Meur - 2011-08-04 16:57:25 Le 04/08/2011 16:32, Thomas White, MD, MS, MA a écrit : > All (but mostly Thibault and Carsten)- > > I'd like input on the desired way to support cascading relevance when > at least one of the variables is irrelevant. This wiki pages shows a > few dozen examples and some proposed results - > http://docs.limesurvey.org/Expression+Manager+Roadmap , with room for > your comments for each example. > > They underlying questions are: > (1) Which operators should always return false if any of their > arguments are irrelevant? > (a) Comparators? (==, !=, >, >=, <, <=) > (b) Math? (+, -, *, /, +=, -=, *=, /=) > (c) Logic (&&, ||, !) > (2) Can we safely apply the above to just plain variables (e.g. a == > b), or do people truly want this to apply to sub-equations (e.g. > (a+b)==c). Cascading irrelevant (N/A) status to sub-equations is harder. > (3) Is it always safe to NOT return false for functions that take > multiple arguments - like sum(a,b,c), if(a,b,c), list(a,b,c), > max(a,b,c) - e.g. each sub-equation (the parts between commas in the > function call) will be false, but an argument will be passed to the > function. Hum, I've seen the table on the wiki page... but wouldn't it be confusing for our users if operators behave differently ? In fact I think would return false for any Expression using a non-available (N/A) value, this includes 1a, 1b,1c and I'm afraid 2 as well. => Is (2) difficult if we rewrite array_filter (the only sub-question filtering feature) using EM? Of course this requires to add the relevanceXXX you described in your last commit for sub-question as well. I wouldn't assume that (3) is safe in all cases. It is really up to the function to define if it can process non-available arguments and still return a meaningful result. sum() seems, indeed, a good candidate if non-available arguments are set to "0". But we can't make this a general rule. IMHO: * ExpressionManager should "throw an exception" if a reference to a non-available value is found whatever the expression is and in this case return FALSE. This would avoid having to imagine all combinations of operators and will remain consistant (since simple) * the only function that would "mask" this exception would be the is_relevant() function. * we could imagine a new notation {Q3:0} which could refer to the value of Q3 if available or '0' if not available (in this case, this notation should mask the Exception as well). This is only my first impression, though I have not stepped into the code. Thibault