boolean operations

[Charles Dietz]

Consider:

   i = 4
   j = 3
   IF i AND j THEN MSGBOX "true" ELSE MSGBOX "false"      'true
   IF i XOR j THEN MSGBOX "true" ELSE MSGBOX "false"      'true

It seems to me that the second IF statement should be treated as a boolean
operation, just as the first one. Since i > 0 and j > 0, i and j are both
true so the result should be false. I also note that:

IF (i > 0) XOR (j > 0) THEN MSGBOX "true" ELSE MSGBOX "false" --> 'false

Can anyone shed some light on this inconsistancy? Did PowerBasic intend
for only the AND to be a boolean operation?




------------------

[Lance Edmonds]

Short Circuit Evaluation
PowerBASIC features short-circuit evaluation of relational expressions. This optimization means that evaluation of a relational expression in an IF, IF/END IF, DO/LOOP, or WHILE/WEND is terminated just as soon as it is possible to tell what the result will be. For example:

IF LEN(a$) AND MyFunc&(a$) THEN CALL ShowText("Ok!")

In the above example, if LEN(a$) is zero, then there is no further need to evaluate the expression, because 0 and anything will always be FALSE. So, if LEN(a$) is zero, MyFunc() is not called at all, and ShowText() is not executed.
To give short-circuit optimization an extra boost, AND is treated as a Boolean operator rather than a bitwise operator, and this can sometimes produce unexpected results. For example, consider the following expression:

a& = 4
b& = 2
IF a& AND b& THEN ShowText("TRUE") ELSE ShowText("FALSE")

Applying the traditional BASIC bitwise evaluation, you would expect to see FALSE displayed because (4 AND 2) = 0. Due to the short-circuit optimization though, each value is treated as a Boolean, just as if you had written:

IF ISTRUE a& AND ISTRUE b& THEN …

If you believe this may be a problem for your particular code, you can disable the short-circuit evaluation by surrounding the entire conditional in parentheses:

IF (a& AND b&) THEN ShowText("TRUE") ELSE ShowText("FALSE")

The parentheses force the entire expression to be evaluated, so AND reverts to being a bitwise operator.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Scott Turchin]

WOw, so that's why that happens!
I've always just done this method for consistency, probably from the old pascal days or something:

If (this or that) and (that or this).........
Not to mention it helps me mentally keep them separated so I can visualize the result of one before the next result.....


Thanks Lance!

Scott

------------------
Scott

[Charles Dietz]

Thanks, Lance.

It was precisely because of your explanation for AND (p.260 in the manual)
that prompted me to try the XOR boolean operator in the first place. like
the AND operator, I expected these two statements to produce the same result.

IF i XOR j THEN MSGBOX "true" ELSE MSGBOX "false" 'true
IF ISTRUE i XOR ISTRUE j THEN MSGBOX "true" ELSE MSGBOX "false" 'false

Is it because of the short circuit evaluation that AND is treated differently
than XOR? The XOR operator requires an examination of both integers before
a truth value can be assigned, whereas with AND a truth value can sometimes
be assigned after examination of only the first integer.

------------------

[Lance Edmonds]

Short Circuit evaluation only applies to the AND and OR operators. All others are bitwise.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Tom Hanlin]

Is it because of the short circuit evaluation that AND is treated differently
than XOR? The XOR operator requires an examination of both integers before
a truth value can be assigned, whereas with AND a truth value can sometimes
be assigned after examination of only the first integer.

Just so. PB uses short-circuit evaluation where it can, not where it can't.
Some day, Visual Basic may do this also.

------------------
Tom Hanlin
PowerBASIC Staff

[Josh Forster]

VB.NET already does.

Josh

------------------

[Lance Edmonds]

Originally posted by Josh Forster:
VB.NET already does.
Josh

Ouch! Another thing that will cause problems for folks porting from VBx -> VB.NET.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Josh Forster]

Ouch! Another thing that will cause problems for folks porting from VBx -> VB.NET.

It is yet another blessing of VB.NET. It is finally moving to the
next level.

Josh




[This message has been edited by Josh Forster (edited April 17, 2001).]