Re: Evaluation of complex conditions

2011-10-06 Thread Pete
Yes, that's what I would have expected but just double checking since someone mentioned otherwise - back to "precedence" versus "evaluation" again I think. Pete Molly's Revenge On Thu, Oct 6, 2011 at 2:38 PM, Richard Gaskin wrote: > Pete wrote: > > I wrote a cou

Re: Evaluation of complex conditions

2011-10-06 Thread Bob Sneidar
Right logical expressions are left to right. I may have been confused on the issue. There would be no advantage to doing it any other way so far as I can see. Bob On Oct 6, 2011, at 2:13 PM, Pete wrote: > Thanks Graham. Yes, someone else provided an example of the function you > mentioned t

Re: Evaluation of complex conditions

2011-10-06 Thread Richard Gaskin
Pete wrote: I wrote a couple of functions (condition1 and condition2), each of which puts its identity after a script variable named myResult then returns true. I then wrote the following: put empty into myResult if condition1() is true and condition2() is true then put myResult As expected,

Re: Evaluation of complex conditions

2011-10-06 Thread Pete
Thanks Graham. Yes, someone else provided an example of the function you mentioned to illustrate how things work. But I cannot reproduce the behavior mentioned when conditions are enclosed in parens - the order of evaluation doesn't seem to be affected. I wrote a couple of functions (condition1

Re: Evaluation of complex conditions

2011-10-06 Thread Graham Samuel
Yes, in any 'and' where the first condition is false, then the second condition is not evaluated; similarly in any 'or', if the first condition is true, the second isn't evaluated. Parentheses alter the order of evaluation as others have said. It's easy to prove this by writing a script where t

Re: Evaluation of complex conditions

2011-10-06 Thread Alex Tweedly
On 06/10/2011 18:14, Ken Ray wrote: There are certain times where parens are necessary (I just wish I could remember specifically where and when). It *is* a good practice to put expressions in parens for readability, especially when it comes to working with objects. Compare: My favourite examp

Re: Evaluation of complex conditions

2011-10-06 Thread Pete
Thanks Ken. Like you, I do tend to put parens around individual conditions in a multi-condition if statement. I guess as long as all the conditions are in parens, it won;t matter if parens change the order of evaluation. Thanks to all for the clarifications. Pete Molly's Revenge

Re: Evaluation of complex conditions

2011-10-06 Thread Ken Ray
On Oct 6, 2011, at 11:40 AM, Pete wrote: > Thanks Alex, makes total sense with the examples you provided. > > The only remaining question in my mind is if the use of parens changes > anything - a post yesterday suggested that putting a condition in parens > causes it to be evaluated ahead of the

Re: Evaluation of complex conditions

2011-10-06 Thread Pete
Thanks Alex, makes total sense with the examples you provided. The only remaining question in my mind is if the use of parens changes anything - a post yesterday suggested that putting a condition in parens causes it to be evaluated ahead of the other conditions but I can't make that happen in you

Re: Evaluation of complex conditions

2011-10-06 Thread Alex Tweedly
Don't confuse "operator precedence" and "order of evaluation". precedence tells you how the results of individual parts of the calculation are combined. For instance, 1+2*3+4 will give 11 (i.e. multiplication is higher precedence than addition, so the 2 is multiplied by the 3 and then that is

Re: Evaluation of complex conditions

2011-10-05 Thread Pete
I just read the section in the manual about operator precedence and I think perhaps I'm even more confused than I was! It details a strict order of precedence which seems to contradict the knowledge that condition evaluation proceeds from left to right and stops as soon as a false one is found. M

Re: Evaluation of complex conditions

2011-10-05 Thread stephen barncard
yeah , I don't know, sometimes stuff doesn't work exactly right so I try something else like if a is true then switch case b = true case c = true do whatever break end switch end if or try reversing and/or if a is true then if (b is true and c is true) then do whatever end if e

Re: Evaluation of complex conditions

2011-10-05 Thread Pete
No, I mean: If a is true then if (b is true or c is true) then do whatever end if end if I'm pretty sure if a was false, the second condition wouldn't be evaluated. But you raise an interesting point - in your example, does the condition inside the parens truly get evaluated first?

Re: Evaluation of complex conditions

2011-10-05 Thread Bob Sneidar
Yes, if by nested you mean: a is true and (b is true or c is true) The statement in parenthesis gets evaluated first. Bob On Oct 5, 2011, at 2:20 PM, Pete wrote: > Thanks, that's good to know. I'm looking at using a pretty complex > condition with some of the conditions being trivial but ot

Re: Evaluation of complex conditions

2011-10-05 Thread Pete
Thanks, that's good to know. I'm looking at using a pretty complex condition with some of the conditions being trivial but others taking up significant database access so sounds like I should leave the db access conditions until last. Hmmm, now I wonder if nested if statements make any difference

Re: Evaluation of complex conditions

2011-10-05 Thread Richard Gaskin
Pete wrote: I'm wondering how LC evaluates If statements with multiple conditions. Are all conditions evaluated before the overall result is checked for true or false, or does evaluation proceed left to right and stop as soon as a condition is found to be false? Whichever method is used, is it

Evaluation of complex conditions

2011-10-05 Thread Pete
I'm wondering how LC evaluates If statements with multiple conditions. Are all conditions evaluated before the overall result is checked for true or false, or does evaluation proceed left to right and stop as soon as a condition is found to be false? Whichever method is used, is it affected by so