IF statement

[40wattstudio]

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.

[OldMoses]

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.

[SMcNeill]

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.

[40wattstudio]

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.

[SMcNeill]

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 .

[Pete]

Yep, now you're getting it. Also, look into ELSEIF

Pete

[40wattstudio]

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.

[luke]

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.

[40wattstudio]

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.

[bplus]

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 ;-))

[STxAxTIC]

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.

[bplus]

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.

[Pete]

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

[luke]

Unfortunately short-circuiting isn't a transparent optimisation. Imagine this code:

Code: [Select]

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.

[FellippeHeitor]

In the spirit of QB64's essence, I don't even think it should.