Logical AND operator

[Robert]

Hi Robert,

This was still bugging me this morning.

Because you didn't explicitly state what you expected the output to be from your
LIFE/DEATH program, I sought out some independent insight from Google's BARD.

I fed the C output (only the main() function), to Google's BARD.  I said:
I'm purposely omitting code and directives.  That aside and assuming the
following executes correctly, what would you expect the output to be?

BARD replied:

Assuming the code you provided executes correctly, the output would be:

Life is True
Death is True
Life ANDALSO Death is 1
Life BAND Death is 1

Life is True
Death is False
Life ANDALSO Death is 0
Life BAND Death is 0

Life is False
Death is True
Life ANDALSO Death is 0
Life BAND Death is 0

Life is False
Death is False
Life ANDALSO Death is 0
Life BAND Death is 0


... which exactly matches the results produced by BCX's translation of your program.

I feel now I can get back to my regularly scheduled programming 

Hi MrBcx:

First thought was "Wow ! BCX held up as a standard of comparison."

Second thought was ouroboros

https://en.wikipedia.org/wiki/Ouroboros

and  Second-order-cybernetics



details here.

https://en.wikipedia.org/wiki/Second-order_cybernetics

[MrBcx]

Hi Robert,

This was still bugging me this morning.

Because you didn't explicitly state what you expected the output to be from your
LIFE/DEATH program, I sought out some independent insight from Google's BARD.

I fed the C output (only the main() function), to Google's BARD.  I said:
I'm purposely omitting code and directives.  That aside and assuming the
following executes correctly, what would you expect the output to be?

BARD replied:

Assuming the code you provided executes correctly, the output would be:

Life is True
Death is True
Life ANDALSO Death is 1
Life BAND Death is 1

Life is True
Death is False
Life ANDALSO Death is 0
Life BAND Death is 0

Life is False
Death is True
Life ANDALSO Death is 0
Life BAND Death is 0

Life is False
Death is False
Life ANDALSO Death is 0
Life BAND Death is 0


... which exactly matches the results produced by BCX's translation of your program.

I feel now I can get back to my regularly scheduled programming 

[MrBcx]

I apologize if I am exacerbating the confusion. Anyway, I probably would have said nothing if you had written

ORELSE / ANDALSO are -ALWAYS- translated to Boolean logical conjunction operators.

Sadly, I must count myself amongst the group less adept in the art of word stew.

[MrBcx]

Robert,

The attached file combines your BASIC src and the translated C, side-by-side.

If there are translation errors, please point them out to me by line number.

I noticed you've introduced the BOOL$ function into this discussion.  If that
is a source of concern, let me know and I'll investigate it.  I had nothing to
do with its creation and I've never personally used it.

I'm not looking for a fight.  If something is broken, I'll try to fix it. 
But riddles are a poor way to explain things to me.

[Robert]

Hi MrBCX:

I really should let you that I am not trolling for an argument about semantics, "Boolean", "Logical", "Operations", "Operators" but rather, perhaps obtusely, seeking to clarify my own understanding of the underpinning Boolean operations of bitwise instructions.

It is easy to conflate a Bitwise conjunction on two binary integers with a Logical conjunction on two Boolean expressions as demonstrated in my previous Life / Death post.

I would appreciate any comments you may have on the  extent of bitwise conflation with Boolean Logical Conjunctions. Can the conflation exist beyond the trivial 0 (zero) and 1 (one) (-1 in PowerBASIC)? Are there other bitwise operations that can cause confusion?

I apologize if I am exacerbating the confusion. Anyway, I probably would have said nothing if you had written

ORELSE / ANDALSO are -ALWAYS- translated to Boolean logical conjunction operators.

[Robert]

Kevin Diggins :
<snip>
                ORELSE / ANDALSO are -ALWAYS- treated as boolean operations.
<snip>

It is -ALWAYS- difficult to make rules.
There are -ALWAYS-  exceptions ... usually, that is, most of the time, more often than not.

Code Select Expand


  DIM AS INTEGER Reality
  DIM AS BOOL Life, Death
?
  Life = True
  PRINT "Life is ", BOOL$(Life)
  Death = True
  PRINT "Death is ", BOOL$(Death)
  Reality = Life ANDALSO Death
  PRINT "Life ANDALSO Death is ", Reality
  Reality = Life BAND Death
  PRINT "Life BAND Death is ", Reality
?
  Life = True
  PRINT "Life is ", BOOL$(Life)
  Death = False
  PRINT "Death is ", BOOL$(Death)
  Reality = Life ANDALSO Death
  PRINT "Life ANDALSO Death is ", Reality
  Reality = Life BAND Death
  PRINT "Life BAND Death is ", Reality
?
  Life = False
  PRINT "Life is ", BOOL$(Life)
  Death = True
  PRINT "Death is ", BOOL$(Death)
  Reality = Life ANDALSO Death
  PRINT "Life ANDALSO Death is ", Reality
  Reality = Life BAND Death
  PRINT "Life BAND Death is ", Reality
?
  Life = False
  PRINT "Life is ", BOOL$(Life)
  Death = False
  PRINT "Death is ", BOOL$(Death)
  Reality = Life ANDALSO Death
  PRINT "Life ANDALSO Death is ", Reality
  Reality = Life BAND Death
  PRINT "Life BAND Death is ", Reality
?

  PAUSE



Result:

Code Select Expand


Life is True
Death is True
Life ANDALSO Death is  1
Life BAND Death is  1

Life is True
Death is False
Life ANDALSO Death is  0
Life BAND Death is  0

Life is False
Death is True
Life ANDALSO Death is  0
Life BAND Death is  0

Life is False
Death is False
Life ANDALSO Death is  0
Life BAND Death is  0


Code Select Expand


  Reality=Life &&Death;
  Reality=Life & Death;


[MrBcx]

Hi MrBCX:

Thanks for that.

I would've have known but my dog ate the BCX 7.5.7 memo.

Kevin Diggins : Simplified "OR" and "AND" duality (boolean/bitwise) to two (1999) BCX rules:
                1) OR/AND inside any IF or $IF statement is ALWAYS treated as boolean
                2) OR/AND outside any IF or $IF are ALWAYS treated as bitwise.
               
                You can use ORELSE / ANDALSO when you absolutely need a boolean comparison.
                ORELSE / ANDALSO are -ALWAYS- treated as boolean operations.
               
                These changes -might- break some existing code but I believe mostly it won't. 
                My goal is that these changes / rules will deliver a consistent treatment of
                "OR"/"AND" without needing multiple code blocks for handling special situations
                which previously was unreliable.   

Hi Robert,

Thanks for re-posting that important bullet point from the Revisions file. 

A lot of effort and testing went into BCX during the COVID lock-down period which
led to some genuinely solid improvements.  The AND / OR clean-up exercise topped
that list, in my book. 

Since then, the sum of my changes have enabled me to resurrect a ton of old BCX
code that was written by others but had been broken over the years, all due to a lack
of diligent regression testing of the translator while I was away.  That lone fact gave
rise to my prolonged reluctance to leave BCX 6.2.2.x, as I'm certain you remember.

PS:
For the historically curious among us, the (1999) rules that I referred to are these
few lines of code from 1999 when I was still programming BCX using PowerBasic
for MSDOS and BCX was generating code for Windows 95/98.

  If Lcase$(Stk$(1)) =  "if"  AND  Lcase$(Anyword$)="and" Then Anyword$ = "&&"
  If Lcase$(Stk$(1)) <> "if"  AND  Lcase$(Anyword$)="and" Then Anyword$ = "&"
  If Lcase$(Stk$(1)) =  "if"  AND  Lcase$(Anyword$)="or"  Then Anyword$ = "||"
  If Lcase$(Stk$(1)) <> "if"  AND  Lcase$(Anyword$)="or"  Then Anyword$ = "|"

[Robert]

Hi MrBCX:

Thanks for that.

I would've have known but my dog ate the BCX 7.5.7 memo.

Kevin Diggins : Simplified "OR" and "AND" duality (boolean/bitwise) to two (1999) BCX rules:
                1) OR/AND inside any IF or $IF statement is ALWAYS treated as boolean
                2) OR/AND outside any IF or $IF are ALWAYS treated as bitwise.
               
                You can use ORELSE / ANDALSO when you absolutely need a boolean comparison.
                ORELSE / ANDALSO are -ALWAYS- treated as boolean operations.
               
                These changes -might- break some existing code but I believe mostly it won't. 
                My goal is that these changes / rules will deliver a consistent treatment of
                "OR"/"AND" without needing multiple code blocks for handling special situations
                which previously was unreliable.   

[MrBcx]

This is an assignment:

RetVal = Operand1 AND Operand2       '<------ BITWISE AND


This is an IF THEN statement:

IF it AND 1 THEN                              '<------ LOGICAL AND


Try this:


DIM RetVal

FOR INTEGER it = 0 TO 9
    RetVal = it AND 1
    IF RetVal THEN
        PRINT it, " is odd."
    ELSE
        PRINT it, " is even."
    END IF
NEXT it

PAUSE



0 is even.
1 is odd.
2 is even.
3 is odd.
4 is even.
5 is odd.
6 is even.
7 is odd.
8 is even.
9 is odd.

Press any key to continue . . .

[Robert]

Hi Robert -- I've seen this movie before.

<snip>
  BCX sees and treats

   RetVal = Operand1 AND Operand2

exactly the same as

   RetVal = Operand1 BAND Operand2

<snip>

Yeah, well, uh ...

Code Select Expand


FOR INTEGER it = 0 TO 9
   IF it AND 1 THEN
     PRINT it, " is odd."
   ELSE
     PRINT it, " is even."
   END IF
NEXT it


Result:

Code Select Expand


0 is even.
1 is odd.
2 is odd.
3 is odd.
4 is odd.
5 is odd.
6 is odd.
7 is odd.
8 is odd.
9 is odd.


Code Select Expand


FOR INTEGER it = 0 TO 9
   IF it BAND 1 THEN
     PRINT it, " is odd."
   ELSE
     PRINT it, " is even."
   END IF
NEXT it


Result:

Code Select Expand


0 is even.
1 is odd.
2 is even.
3 is odd.
4 is even.
5 is odd.
6 is even.
7 is odd.
8 is even.
9 is odd.


[MrBcx]

Hi Robert -- I've seen this movie before.

Language ambiguity is the bane of all compiler writers.

This is why ANDALSO was invented and has taken up residence in BCX's lexicon.

Otherwise, BCX sees and treats

   RetVal = Operand1 AND Operand2

exactly the same as

   RetVal = Operand1 BAND Operand2


For illustration, consideration and further discussion:

Code Select Expand



DIM AS INTEGER RetVal, Operand1, Operand2

Operand1 = 11111
Operand2 = 33333

RetVal = Operand1 ANDALSO Operand2
PRINT RetVal

RetVal = Operand1 AND Operand2  ' equivalent to BAND in this syntax
PRINT RetVal

PAUSE

' Thhe following references:
' https://learn.microsoft.com/en-us/dotnet/visual-basic/language-reference/operators/andalso-operator
' Quote:
' "The preceding example produces results of True, False, and False, respectively."
' In the calculation of secondCheck, the second expression is not evaluated because the first
' is already False. However, the second expression is evaluated in the calculation of thirdCheck"

GLOBAL a = 10
GLOBAL b = 8
GLOBAL c = 6

DIM firstCheck, secondCheck, thirdCheck

firstCheck = a > b ANDALSO b > c
secondCheck = b > a ANDALSO b > c
thirdCheck = a > b ANDALSO c > b

PRINT firstCheck      ' 1   TRUE
PRINT secondCheck     ' 0   FALSE
PRINT thirdCheck      ' 0   FALSE

PAUSE



[Robert]

Using BCX 8.0.5

Code Select Expand

RetVal% = Operand1% AND Operand2%

translates to

Code Select Expand

RetVal=Operand1&Operand2;

It should translate to

Code Select Expand

RetVal=Operand1 && Operand2;

From the "C" Standard

6.5.13 Logical AND operator
Syntax

1 logical-AND-expression:
                   inclusive-OR-expression
                   logical-AND-expression && inclusive-OR-expression

Constraints

2 Each of the operands shall have scalar type.

Semantics

3 The && operator shall yield 1 if both of its operands compare unequal to 0; otherwise, it yields 0. The result has type int.


4 Unlike the bitwise binary & operator, the && operator guarantees left-to-right evaluation; if the second operand is evaluated, there is a sequence point between the evaluations of the first and second operands. If the first operand compares equal to 0, the second operand is not evaluated.

For more detail please see the Logical Operators section of the

Operators in C and C++

page in Wikipedia at

https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B