QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: 40wattstudio on December 29, 2020, 08:36:10 pm
-
Let's say you have an IF statement with multiple conditions . . .
IF Condition A = False AND Condition B and Condition C . . . AND Condition Z THEN
Do something
END IF
Now let's suppose that Condition A is True, will the IF statement continue to check all the other conditions or will it skip the rest and move on?
Asking because I have some IF statements with quite a few conditions and trying to see if it's necessary to reorganize things or just leave it as is.
-
That first AND clause requires that condition A be false in order for the IF statement to be considered true. You'de probably have to break it down.
-
In my experience, break it down. Especially if there’s anything more involved like an OR...
IF x AND y OR z THEN.....
Is that (x and y) or z, or is it x and (y or z)??
Its confusing with just 3 elements... Now who the heck can decipher A to Z conditions?
Keep it simple so you (and others) can follow the logic in the future.
-
That first AND clause requires that condition A be false in order for the IF statement to be considered true.
Understood, but would it stop immediately after it sees that condition A isn't what is expected, or does it still have to process the rest of the IF statement?
Alternately, I could write it like this:
IF Condition A = False THEN
IF Condition B AND Condition C . . . AND Condition Z THEN
END IF
END IF
And that would isolate that one condition, but again, I'm not sure if that's even necessary.
-
It processes them all.
As I was mentioning, imagine that last condition was OR Condition_Z... It follows basic order of operations like my math evaluator does, until it gets down to a singular check of condition1 relation condition2.
You’re best served to break it down to eliminate checks, as your example above, if speed is a consideration .
-
Yep, now you're getting it. Also, look into ELSEIF
Pete
-
Perfect! Thanks OldMoses, SMcNeill and Pete! Very good stuff to know! Yes, speed is a consideration in the program I'm working on. I made a simple counter to see how many times the main loop ran in 1 second and noticed that when lots of stuff is going on the number of iterations would sometimes drop significantly. So hopefully this will help alleviate that somewhat.
-
Side note: this behaviour (stop checking conditions once the final result is determined) is called short-circuit evaluation. Some other programming languages do this, QB64 doesn't.
-
Side note: this behaviour (stop checking conditions once the final result is determined) is called short-circuit evaluation. Some other programming languages do this, QB64 doesn't.
Awesome, thanks Luke! I was wondering if there was a special name for it. I'm not sure what all is involved with developing QB64, but it'd be cool if future versions had that behaviour built-in.
-
but it'd be cool if future versions had that behaviour built-in.
I think just nesting the IF's and optional ELSEIF's is way more transparent and easier to follow. Who the heck wants to use a LOGIC Table to predict how a little bit of decision making code is going to work. The -1 for True is bad enough ;-))
-
Short circuit evaluation is a thing that's implemented behind the scenes (supposing we had it). The QB64 coder would be none the wiser if it was there, up to a very small speed boost at runtime.
-
Well what I am saying is nest the IF's yourself (or use ELSEIF's or use SELECT CASE), get the speed boost today PLUS understand your code, specially 2 years, heck 2 weeks, down the line.
-
I prefer just nesting the conditional statements. If the first is false, it skips the others. It was more important back in the QBasic days of slower slower processors. I agree with Bill in that I don't see adding "short circuiting" to QB64 as important, unless it's very simple to implement. It's like putting aerodynamic air valve caps on a sports car. You could, but why bother?
Pete
-
Unfortunately short-circuiting isn't a transparent optimisation. Imagine this code:
DIM SHARED S
IF S >= 0 OR F(2) THEN PRINT S
FUNCTION F(N)
S = N
F = N
END FUNCTION
In the current language that would print 2 because F(2) is always called, resulting in the shared variable being updated. But if we sort-circuited, S >= 0 is true so we'd never evaluate the F(2) and thus print 0.
Some languages (Ada comes to mind) have separate operators; "and" is like QB's AND, but the "and then" operator short-circuits. That'd be difficult to implement in QB64 though.
-
In the spirit of QB64's essence, I don't even think it should.
-
Fell, you almost stole my trademark line...
Just because you can, doesn't mean you should.(tm)
Pete
-
In the spirit of QB64's essence, I don't even think it should.
Agreed.
-
Would EXIT IF not be a form of short circuiting? Or does Short Circuiting apply solely to a situation of multiple logical conditions?
-
Would EXIT IF not be a form of short circuiting? Or does Short Circuiting apply solely to a situation of multiple logical conditions?
that bugs out of the entire IF\THEN block spaghetti style .
What he wants here is to have a situation where meeting one criteria of an IF question ,opens the door so to speak, so any other criteria are ignored.
-
that bugs out of the entire IF\THEN block spaghetti style .
What he wants here is to have a situation where meeting one criteria of an IF question ,opens the door so to speak, so any other criteria are ignored.
Yeah in a series of AND conditions one False Boolean Test (=0) would knock the code execution off the THEN clause and start looking for an ELSE if any (before END IF), it is built in and must require some sort of look ahead in built-in code to know that OR wasn't in that series of ANDs of code line, OR hitting one FALSE it jumps ahead and looks for an OR part to begin evaluating for TRUE.
-
I agree with Bplus
Yeah in a series of AND conditions one False Boolean Test (=0) would knock the code execution off the THEN clause and start looking for an ELSE if any (before END IF), it is built in and must require some sort of look ahead in built-in code to know that OR wasn't in that series of ANDs of code line, OR hitting one FALSE it jumps ahead and looks for an OR part to begin evaluating for TRUE.
because a multi presence of AND could lead to the cortocircuit of the evaluation statement, but we need just one OR or XOR to make a mistake activating the cortocircuit procedure.
So the parser must evaluate BEFORE the OR/XOR options and then from the first to the last AND options....remembering that for OR you can have one or two condition true to get true while for XOR you must have only a condition true to get true
as you can see herehttp://qb64.org/wiki/Bitwise_Operators (http://qb64.org/wiki/Bitwise_Operators)