The "truth" behind AND

[Opry99er]

I've been struggling with a problem the last couple days... I've been really really struggling with a problem.

 

The problem was, how does Extended BASIC ACTUALLY perform the AND function.... Some of the code examples are quite simple:

 

>200 IF A=5 AND B=6 THEN GOSUB 500

 

 

This is very logical, simple, and easy to read.

 

But what about cases wherein AND operates DIRECTLY on numbers?

 

>200 IF A AND B THEN GOSUB 500

 

 

Huh? What does that even mean?

 

Well, some of you know already, but this post is for novices like me who are relatively new to Boolean algebra and bit logic. For those of you who read this and understand it, feel free to disregard the rest of this post....

 

 

The problem arose when I was having a discussion with Adamantyr off board and he sent me a little snippit of code that had the following in it...

 

 

1. 190 IF K AND C THEN 200 ELSE 210

In this case, K=4 and C=15, but the statement was apparently "true" because the program went to line 200.

What in the hell was I supposed to do with that???

I had to dig and research to find out exactly what this does... It isn't directly comparing the two numbers to determine if they are equal... what it does is really neat, and I thought I would share it with those of you who don't yet know.

AND (in XB) takes the value of whatever numbers or variables exist to the left and right of it and breaks them into bits... Binary... I made a little table up while I was figuring this out, and a picture of that table is below.

What you see here are all integers from 1-15, broken down into their binary representations. "AND" simply takes the lowest value between the two and sets it up in binary...

DECIMAL (4)

BINARY (0100)

Okay... Now let's look at the other number, "C"

DECIMAL (15)

BINARY (1111)

How are these two (when compared) said to be true?

Well, AND looks at the most significant bit of the lower number (or the first "1" reading from left to right). In this case, it is in the "4s" place. It then looks at the higher number and sees if the most significant bit of the lower number corresponds to a "1" in the higher number. In this case, you can see that it does.... 15 has a "1" in the 4s place, just like "4".

In this way, the two are said to be "true" where AND is concerned.

Here's a little diagram

          *************************
Place     *  8  *  4  *  2  *  1  *
          *************************
     "4"  *  0  *  1  *  0  *  0  *
          *************************
     "15" *  1  *  1  *  1  *  1  *
          *************************

As you can see, the 4 and 15 share a "1" in the most significant bit of the lower number.

Let's look at two numbers that WILL NOT work.....

2 and 12

          *************************
Place     *  8  *  4  *  2  *  1  *
          *************************
     "2"  *  0  *  0  *  1  *  0  *
          *************************
     "12" *  1  *  1  *  0  *  0  *
          *************************

As you can see, the lower number (2) has it's most significant bit in the 2s place... The 12 binary representation has a 0 (zero) in that place. It is for that reason that 2 and 12 (when on the left and right of AND in Extended BASIC) does not kick out "true".... In the sample code, if K was 2 and C was 12, program function would not pass to line 200... rather, it would pass to line 210, because the comparison returned a "false."

Now... look at the picture I posted near the top of this post.... What the main table represents are all the values that will return a "true" when using AND. Feel free to use it however you want, or don't use it at all.

Anyway, this has been a cool learning experience. Adam gave me the snippit of code, but let/made me figure it out on my own. I am grateful for it. Only took me 2 days to figure out EXACTLY what AND was doing. LOL!!!!

Anyway, for those of you who don't have a background in Boolean math (like me) I hope this helped.

ALSO.... XB supports some other cool Boolean functions as well.

OR

XOR

NOT

Have fun... I sure am.

 

 

 

[+Schmitzi]

1. 190 IF K AND C THEN 200 ELSE 210

I think this means: IF K has any value (=exists) AND IF C has any value (=exists) THEN 200 ELSE bla

[+mizapf]

You mean if they have non-zero values? Because K and C clearly exist (I can see them!).

This is the problem with BASIC operators, compared to the similar ones in C(++) / Java etc.

In those languages there are two ANDs: & and &&. The first one is a bitwise AND, the second is a boolean AND. For instance:

Suppose the variables k and c have values 10 and 21. Decimal 10 is binary 00001010, decimal 21 is 00010101. On one hand, this means that a bitwise AND will have no bit position where both operands have ones. Accordingly,

if (k & c) dothis; else dothat;

will execute dothat.

On the other hand, both values are non-zero. When cast to boolean, an integer will become true when non-zero and false when zero. So for this value assignment we have true && true and you already guessed that

if (k && c) dothis; else dothat;

will execute dothis.

#include <stdio.h>

void main() {
   int k=10;
   int c=21;

   if (k&c) printf("this\n");
   else printf("that\n");

   if (k&&c) printf("this\n");
   else printf("that\n");
}

Edit: Java will not compile those lines because it has a stricter type checking and no such implicit casts like C. So we will get this:

Testt.java:7: error: incompatible types: int cannot be converted to boolean
   if (k&c) System.out.println("this\n");
        ^
Testt.java:10: error: bad operand types for binary operator '&&'
   if (k&&c) System.out.println("this\n");
        ^
  first type:  int
  second type: int

Edited May 2, 2015 by mizapf

[+Schmitzi]

yes Mizapf, right. so pls forget my post

I´ve mangled that with DOS-Commmands

IF DEFINED K IF DEFINED C ECHO bla

sorry

[+mizapf]

No need to be sorry, you pointed to yet another meaning of AND in a programming language.

[Dexter]

In XB you could even have this:

10 IF A THEN GOTO 100 ELSE GOTO 200
.
.
100 REM TRUE (A<>0)
.
.
200 REM FALSE (A=0)

Which means: if true, (A<>0) then goto 100, else, if not true, (A=0) then goto 200.

So your statement:

>200 IF A AND B THEN GOSUB 500

I think it means: if A<>0 and B<>0 then gosub 500

 

[+mizapf]

@Dexter: No, the Extended Basic AND seems to be a bitwise AND. That is, it corresponds to the & operator from C, not to the &&.

[+Schmitzi]

it is like MiZapf mentioned, bitwise.

 

IF A THEN bla means IF A <> 0 OK

 

but

 

IF A AND B compares the bits, and is NOT a combination of (IF A) AND (IF B) THEN

[+Schmitzi]

Dexter, what you and me mean would work with:

 

IF A THEN IF B THEN gosub 500

 

like your if A<>0 and B<>0 then gosub 500

 

[Dexter]

It seems you're right with:

 

Suppose the variables k and c have values 10 and 21. Decimal 10 is binary 00001010, decimal 21 is 00010101. On one hand, this means that a bitwise AND will have no bit position where both operands have ones. Accordingly,

if (k & c) dothis; else dothat;

will execute dothat.

However, I just tried my example:

which seems also true.

 

Or am I confused with using one or two arguments?

 

Sorry if I'm completely here.

 

Edit

 

Thanks mizapf and schmitzi, I understand completely.

Edited May 2, 2015 by Dexter

[+Schmitzi]

....

[Dexter]

LOL, I think for me it's going to be a:

[JamesD]

I've never cared for the way BASIC deals with bitwise and logical AND.

This is sort of repeating what has been said but...

100 IF A AND B THEN GO TO 1000 <- this should be a bitwise A & B followed by a test of the result for not equal zero.

If A = 1 and B = 2 you end up not executing the GO TO because different bits are set.
As long as you only use values of 0 and 1 for both A and B you can think of it as FALSE and TRUE but once you deal with other values all bets are off because the bitwise AND could cancel out bits even though both values are non-zero.

100 IF A>0 AND B>0 THEN GO TO 1000 <- this guarantees you have the equivalent of a logical AND when A or B are not just 0 or 1.

[RXB]

What about:

 

IF A*B THEN 1000 ELSE 2000

 

A=0 times B=2 equals 0 GOTO 2000

A=1 times B=0 equals 0 GOTO 2000

A=1 times B=2 equals 2 GOTO 1000

 

Instead of using the AND between A>0 AND B>0 just use multiplication as logic.

 

________________________________________________________________________

 

If you have a different situation like A=7 and B=2 then use:

 

IF A*B=14 then 1000 ELSE 2000

Edited May 2, 2015 by RXB

[JamesD]

What about:

 

IF A*B THEN 1000 ELSE 2000

 

A=0 times B=2 equals 0 GOTO 2000

A=1 times B=0 equals 0 GOTO 2000

A=1 times B=2 equals 2 GOTO 1000

 

Instead of using the AND between A>0 AND B>0 just use multiplication as logic.

 

________________________________________________________________________

 

If you have a different situation like A=7 and B=2 then use:

 

IF A*B=14 then 1000 ELSE 2000

The first suggestion would work well and may be faster than my suggestion. Someone would have to benchmark it to verify that though.

 

The 2nd fails if A=2 and B=7 but would certainly work if that is never the case.

 

*edit*

Keep in mind that what is faster with the interpreter may not be with the compiler. A multiply may take more clock cycles than multiple comparisons against 0.

Edited May 2, 2015 by JamesD

[Opry99er]

Yea, I tried most of the above using small programs just like you guys did... It kept coming back with goofy results that didn't match my hypotheses...

 

When I got lost, it was suggested that I look up Boolean algebra for some insight.

 

That is where I came across the bitwise comparisons. That was great and all, but I still didn't know precisely WHAT the check was CHECKING. The XB manual has a short blurb on this and a table (which wasn't much help) but it didnt click for me.

 

Wasn't until I wrote out the binary reptesentation of all integers from 1-15 and tested on the TI that it became obvious that the answer to the riddle was the most significant bit of the lowest number.

 

My initial thoughts were "if both are <>0 then it is true" and "if both are equal values then it is true" but neither played out the way I expected in XB application.

 

The table on the left of the picture I posted in the first post gives you the full scope of true comparisons from 1-15. Since "1" is simply in the "1's" place, any odd number when compared will return true, while any even number will return false.

 

I just find this fascinating...

Edited May 2, 2015 by Opry99er

[+Lee Stewart]

Arithmetic operations are always slower than Boolean operations in XB because arithmetic operations always use floating-point operations on 8-byte numbers, whereas Boolean operations use only 16-bit integers. [Edit: In fact, XB will complain if you use numbers outside the -32768 to +32767 range for Boolean operations.]

 

...lee

Edited May 2, 2015 by Lee Stewart

[+OLD CS1]

No need to be sorry, you pointed to yet another meaning of AND in a programming language.

 

Right. I am used to var1 AND var2 resulting in TRUE if var1 and var2 both contain non-zero values.

[+Lee Stewart]

In TI Extended Basic, The order of precedence of operations, left to right, top to bottom (operations in ‘[]’ indicate equal precedence operations that are evaluated as they appear, left to right) is

1. Parenthetical expressions: always evaluated first
2. Arithmetic: ^ [* /] [+ -]
3. Relational: [= <> < <= > >=]
4. Boolean (logical): NOT XOR AND OR

Obviously, stringing together a lot of operations with no parentheses will be confusing and difficult to read and debug. If you must be complicated, it is best to organize your logic with parentheses. Simple is better.

Relational operations always result in a 16-bit value of -1 (all bits on) for true or 0 (all bits off) for false. The only, really confusing operator is ‘=’, simply because it is the same as the assignment operator. In the following example, everything to the right of the first ‘=’ is relational, with each operator producing a -1 (true) or false (0):

In line 140, the expression on the right of the assignment operator is evaluated as follows:

A = B --> 10 = 10 --> true (-1)
-1 = C --> -1 = 10 --> false (0)
E = 0

In line 150:

A = B --> 10 = 10 --> true (-1)
-1 = D --> -1 = -1 --> true (-1)
F = -1

Boolean operations always produce a 16-bit value that is the result of a bitwise operation.

As indicated or implied by others above, The IF statement tests whether an expression is false (0). As far as IF is concerned, there is no single value for true. It considers any non-zero value to be true.

...lee

[+Lee Stewart]

 

Right. I am used to var1 AND var2 resulting in TRUE if var1 and var2 both contain non-zero values.

 

Not in XB! If var1 = -21846 (alternating bits from the right are off) and var2 = 21845 (alternating bits from the right are on), the result will be: var1 AND var2 = 0 or FALSE.

 

...lee

[+OLD CS1]

 

Not in XB! If var1 = -21846 (alternating bits from the right are off) and var2 = 21845 (alternating bits from the right are on), the result will be: var1 AND var2 = 0 or FALSE.

 

...lee

 

Yup. That is pretty cool, and I am almost certain that is unique in BASIC dialects.

[+Schmitzi]

...

 

[+Lee Stewart]

 

Yup. That is pretty cool, and I am almost certain that is unique in BASIC dialects.

 

That would surprise me because they are clearly Boolean operators and those are always bitwise.

 

...lee

[+Lee Stewart]

 

Yup. That is pretty cool, and I am almost certain that is unique in BASIC dialects.

 

H-m-m-m...Perhaps I misunderstood you. Did you mean, with respect to Boolean operations, that XB is unique among BASIC dialects—or that all BASIC dialects are unique among all programming languages?

 

...lee

[+OLD CS1]

 

H-m-m-m...Perhaps I misunderstood you. Did you mean, with respect to Boolean operations, that XB is unique among BASIC dialects—or that all BASIC dialects are unique among all programming languages?

 

...lee

 

That I do not recall any other BASIC I worked with being a bit-wise AND, which would make XB unique in my experience.