The "truth" behind AND

[+Lee Stewart]

In keeping with Owen’s intended educational tone of this thread, I should attempt to explain my statement, “Boolean operations always produce a 16-bit value that is the result of a bitwise operation.” in post #19 above:

 

Let’s construct a truth table for two variables x and y for the three binary Boolean operations XB supports (AND, OR, XOR):

x  y | AND OR XOR
-----+-----------
T  T |  T  T   F
T  F |  F  T   T
F  T |  F  T   T
F  F |  F  F   F

For (x AND y) to be true, both x and y must be true. For (x OR y) to be true, only one needs to be true. For (x XOR y) to be true, one must be true while the other must be false. Bitwise operators perform the above operations on each bit of the integers being compared. For XB, these are 16-bit numbers. For an operation on bits, a set or on bit = 1 and a reset or off bit = 0. For Owen’s ‘AND’ example, using K = 4 and C = 15:

         1 1 1 1 1 1 
   bit#: 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
         -------------------------------
      K: 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 =  4d
      C: 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 = 15d
         -------------------------------
K AND C: 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 =  4d

What if C were 11 instead of 15, i.e., what it you wanted to “mask out” bit #2?:

         1 1 1 1 1 1
   bit#: 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
         -------------------------------
      K: 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 =  4d
      C: 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 = 11d
         -------------------------------
K AND C: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 =  0d

As you can see, each bit is ANDed to get the result.

 

...lee

[Opry99er]

Sweet description there Lee!

 

That makes the table/descriptive blurb in the XB Manual a 'bit' more understandable!

[Opry99er]

What I found really interesting with XOR is that T and T make F.

 

At first I couldnt come up with a real-world example in which this could be useful, but it would have saved me alot of heart ache in my programming of my menu functions in my game project.

 

If you want to send control to a subroutine based on polling variables for certain inventory items, it helps to be able to use an eXclusive OR in certain situations.

 

I will now be able to replace 5-6 lines of code with a single XOR.

[JamesD]

 

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

10 PRINT 1 AND 2

 

Results are 0 in Microsoft BASIC on a CoCo

Results are 1 in Applesoft II

Results are 0 on a Plus/4

Any wonder why I don't like the way BASIC handles it.

It's kinda like RND(0) or RND(1)

 

Atari BASIC prints 1

 

*edit*

The NEC Trek prints 0

The Amstrad CPC prints 0

The Oric Atmos prints 0

The Hector prints 0

The JR-200 prints 0

The ZX Spectrum refuses to accept that as input because it likes to be different... and I couldn't find how to input AND without looking up a photo of the "keyboard"

But the QL printed a 1 so I'm sure the Speccy will too

The BBC Micro prints 0

The Thomson TO8 prints 0 in spite of it's stuck up keyboard layout

The Aquarius prints 0

The Adam prints 1 because it must to be semi Applesoft compatible

The Microbee barfed up an error and several machines scoffed at the idea that BASIC should be built in

Edited May 3, 2015 by JamesD

[+Schmitzi]

yep

 

 

[+Schmitzi]

...

[JamesD]

What I found really interesting with XOR is that T and T make F.

 

At first I couldnt come up with a real-world example in which this could be useful, but it would have saved me alot of heart ache in my programming of my menu functions in my game project.

 

If you want to send control to a subroutine based on polling variables for certain inventory items, it helps to be able to use an eXclusive OR in certain situations.

 

I will now be able to replace 5-6 lines of code with a single XOR.

XOR, one or the other but not both

[JamesD]

yep

 

 

GW BASIC is pretty much exactly like Extended Color BASIC on the CoCo

[+OLD CS1]

hehehe Applesoft does not surprise me. The Plus/4 would be Commodore BASIC 3.5 (I think, maybe 4.0,) the Commodore 64 is 2.0, which I doubt should be different and which may explain some neat programming failures.

[JamesD]

hehehe Applesoft does not surprise me. The Plus/4 would be Commodore BASIC 3.5 (I think, maybe 4.0,) the Commodore 64 is 2.0, which I doubt should be different and which may explain some neat programming failures.

Technically, all Commodore versions, Applesoft, OSI and a couple other 6502 machines (Microtan, Kim 1?) were Microsoft BASIC.

The reason Appplesoft is different is because Integer BASIC had been that way. Most Applesoft oddities come from that.

[Stuart]

What I found really interesting with XOR is that T and T make F.

 

At first I couldnt come up with a real-world example in which this could be useful, but it would have saved me alot of heart ache in my programming of my menu functions in my game project.

 

Well, one 'use' is to swap the values in two variables without the use of a third variable. This screws my head every time I think about it. Try this:

 

100 X=1234

110 Y=5678

120 PRINT X,Y

130 Y=X XOR Y

140 X=Y XOR X

150 Y=X XOR Y

160 PRINT X,Y

[+mizapf]

 

x' = (y' ^ x) = (x ^ y) ^ x = y ^ (x ^ x) = y
y'' = (x' ^ y') = (y' ^ x) ^ y' = (x ^ y') ^ y' = x ^ (y' ^ y') = x

 

Yeah, looks good. XORa(x) = (x ^ a) is invertible for every a, and the inversion is it by itself.

[+Schmitzi]

awesome. wizards of var - BitShifters

[matthew180]

@Owen: You have to be careful with high-level languages and their use of logical vs bit operations. Also, as you have found out, the same operator changes based on *context*. Personally I have always hated this, and probably the most clear example is the infamous '=' which can be assignment or equality depending on its use:

 

Assignment:

A = 10

 

Equality:

IF A = 10 THEN ...

 

Some languages have different symbols for assignment vs equality (like C/C++) but you can still shoot yourself in the foot:

 

if ( a = 10 )

 

That is valid and will assign 10 to the variable 'a', then evaluate 'a' and since it is not zero it will be a true statement. Most of the time the programmer meant to do this:

 

if ( a == 10 )

 

Which tests for equality (in C/C++ the double equal is equality.) IMO Pascal got it right with the token colon-equal (which will probably show up in the form as an icon of some sort if I write it...) : = (without the space) for assignment.

 

In most languages, anything other than zero is considered true. Only zero and sometimes special tokens (like a real 'NULL') are considered false. But this is not always the case and I'm sure there are languages out there that break the generally accepted rules. This is why I hate code that is written like this:

 

IF A THEN

 

If 'A' what??? If 'A' is *true*, i.e. not zero (usually). So why not just write:

 

IF A<>0 THEN

 

Now it is clear and there are no mistakes or assumptions.

 

Anyway, be careful and test small programs so you know what the operators are really doing. And never assume things work the same between any two languages.

[+mizapf]

Some languages have different symbols for assignment vs equality (like C/C++) but you can still shoot yourself in the foot:

 

if ( a = 10 )

 

That is valid and will assign 10 to the variable 'a', then evaluate 'a' and since it is not zero it will be a true statement. Most of the time the programmer meant to do this:

 

if ( a == 10 )

 

Which tests for equality (in C/C++ the double equal is equality.)

 

This is what I really enjoy in Java. Unlike in C, boolean is not int, and you cannot cast from one to the other. Thus, "a=10" returns 10 as an integer (as in C), but "if" requires boolean.

 

The reason for this behavior of C is that C actually does not have a boolean type, and the creators of C++ were not brave enough to break with this legacy.

[Opry99er]

@Matthew

 

200 IF POINTS=SOLID THEN GOSUB 1000

.

.

.

1000 PRINT "THANKS!"

 

>RUN

 

 

THANKS!

 

 

**READY**

 

>