The Best-Kept Secret of Programming |

Note: the following, although presented in old line-numbered BASIC format,
is applicable to Visual BASIC and spreadsheets as well. These methods
are particularly useful in streamlining PowerBASIC macros.

The GW-BASIC User's Guide and Reference, Microsoft, 1989, contains a small section explaining the function of relational operators. The text begins:

"Relational operators let you compare two values. The result of the comparison is either true (-1) or false (0). This result can then be used to make a decision regarding program flow."

The GW-BASIC Reference, McGraw-Hill, 1990, features a similar section with this sentence:

"When two values are compared, the relational operators return
a result of ~~-1~~ (true) or 0 (false)."

The GW-BASIC 3.20, Epson, 1986, is nearly as terse:

"A logical operation uses Boolean mathematics to define a
logical connection between the results ~~(-1 or 0)~~ of relational
operations. You can use logical operators to connect two or more relations
and return a true or false value to be used in a decision."

Those manuals make **no** further reference to the numeric
value of logical expressions, except in regards to the usage of the bitwise
AND/OR, which is a different construct. Also, despite extensive
searching, I have found no other web page that addresses this issue, per se.

"Big deal", you might say. Computers work with numbers.
Every relational expression, such as ~~P > Q~~,
is internally evaluated for its relative truthfulness. The CPU's logic gates
process such expressions using ~~numbers —~~ specifically, 0 and -1 in the
case of BASIC. This should come as no surprise. My response would be,
"Those arithmetic values are immensely useful;
why is their application being universally ignored?"

Before going further, I would like to share my first experience as a BASIC
programmer, on a ~~Commodore-64~~. At the BASIC prompt, I entered the
statement, ~~PRINT 1=2~~. What happened?
A zero appeared on the screen, which was not what
I expected. No error ~~message —~~ just a zero. The absence of an
error condition told me that such a statement had a valid meaning to BASIC.
Hmm. Then I entered this command: ~~PRINT 2=2~~.
What happened? Again, no error message, but this time a
~~-1~~ appeared. Hmm. I tried it again:
~~PRINT 3 <= 4~~. This also begat a
~~-1~~.

It seems that relational expressions need not exist only within an
**IF** statement or as a condition of a
**WHILE** loop; yet those are the **only** constructs in
which one ever sees them being used. Which brings us to
The Great Unknown Of (BASIC) Programming, and you may
have heard it here first:

The relational and logical operators can be used in
*ANY* mathematical context!

A corollary to that is:

Any LOGICAL CONDITION can be expressed
as an *ALGEBRAIC EQUATION*

That means formulas. (It also happens to mean that the keywords
**IF** and **THEN** are
technically redundant, and that any program can be written without them!
But that's the stuff of another article, and those keywords do make life easier.
More about that later.) Let us see some examples, which I have termed
"Booleans" for lack of a more
imaginative designation.

40 X=2: IF Y<>0 THEN X=3

can be written as:

40 X=2 -(Y<>0)

The term (Y<>0) is evaluated. If true, it is
assigned a value of -1. The expression becomes
~~X = 2-(-1)~~, or 3. Should
~~Y = 0~~, then ~~(Y <> 0)~~
would be false, and its value 0. Then,
~~X= 2-(0)~~, or 2.

A multiplier can be utilized to effect a specific change in value:

180 IF A=B THEN A=A-4

can be shortened to:

180 A=A -4*-(A=B)

which might as well be written as:

180 A=A+4*(A=B)

4*(-1) is subtracted from A, if A entered the equation equal to B.

Logical operators may be included in the mix.

The logical **OR** is equivalent to
arithmetic **ADDITION**:

230 IF P=5 OR P=6 THEN Q=Q*2

becomes:

230 Q=Q -Q*(P=5 OR P=6)

This also could be written as:

230 Q=Q -Q*((P=5)+(P=6))

The logical **AND** equates to arithmetic
**MULTIPLICATION:**

370 IF R>0 AND S=7 THEN T=5 ELSE T=2

could be written as either:

370 T=2 -3*(R>0 AND S=7)

or:

370 T=2 +3*(R>0)*(S=7)

Notice the difference in the sign in front of the 3.
In the first case, there is but one Boolean term, which will evaluate to
~~(-1)~~ if true. In the second case, there are two
Booleans, which would generate ~~(-1)*(-1)~~ if true.
An **ODD** number of multiplied terms **CHANGES** the sign;
an *EVEN* number **MAINTAINS** it. Including
the logical operators in the code is more readable; but converting to pure algebra is
more concise. It is the user's option.

One might be able to combine several statements, and string comparisons are
fair game:

230 IF D$=E$ THEN J=J-1 |

232 IF F<=3 THEN J=J+2 |

can become this:

230 J=J +(D$=E$) -2*(F<=3)

Coding can be particularly concise when zeroes are involved:

380 D=0: IF A<>0 AND B<>0 AND C<>0 THEN D=8

can be reduced to:

380 D=-8*(A*B*C<>0)

D goes from zero to 8 only if A, B, and C all have value.
Now **that's **pretty.

Nested conditional statements can be assimilated:

230 IF R<0 THEN Q=Q+1: IF S=0 THEN Q=Q+1

equates to:

230 Q=Q+(R<0)*(1-(S=0))

Nothing happens unless R<0, whereupon Q is incremented by 1 or 2, depending upon the value of S.

These code samples are well and good, and one can readily see that Booleans streamline code in fine style, but might they serve a grander purpose? Are there any truly useful applications for this stuff? The answer is an unequivocal "Yes." One example is in the creation of a BASIC Function, which definition is limited to a single program statement:

HANDLING LETTER CASE

10 '----------[ convert 1 character to uppercase ]---------- |

12 DEF FNUP$(C$) = CHR$(ASC(C$) -32 * (ASC(C$)>96) * (ASC(C$)<123)) |

The lowercase letters are Ascii 97-122; uppercase letters are Ascii 65-91, or
32 less. If C$ is in the range of Ascii ~~97-122,~~
then ~~32 *(-1)*(-1)~~ is subtracted from the Ascii value of
C$, which changes it to an uppercase letter. Other
characters are unaffected, as the Boolean adjustment to the Ascii value would become
~~-32*(0)*(0).~~

This function would simplify the code to convert a string of text:

800 '-----------[ SUB: convert A$ to uppercase ]--------------- |

810 FOR J=1 TO LEN(A$): MID$(A$,J,1) = FNUP$(MID$(A$,J,1): NEXT: RETURN |

If desired, one could convert input to lower case by changing the formula's numbers to +32, 64, 91.

Granted, in this context FNUP$ doesn't do anything that cannot be replicated by traditional methods, but the code is much cleaner. This function really shines in the simplification of INPUT routines. Say that the user is to be prompted for a response to a Yes/No question. A portion of the subroutine might look like this:

470 A$ = INPUT$(1) |

480 IF A$="Y" OR A$="y" THEN {do this} |

490 IF A$="N" OR A$="n" THEN {do that} |

Repetitive double-trapping of various alpha characters throughout a program can become quite tedious; but now those days are gone, because henceforth you will code thusly:

470 A$ = FNUP$(INPUT$(1)) |

480 IF A$="Y" THEN {do this} |

490 IF A$="N" THEN {do that} |

This next example combines FNUP$ with another nifty Boolean shortcut. Let's say that a user is asked to select a letter option from a menu. Program control would branch to one of several subroutines, depending upon the response.

---- MENU ---- |

(M) morning |

(A) afternoon |

(E) evening |

(L) late |

500 PRINT "Select a time:"; |

510 A$ = FNUP$(INPUT$(1)) |

520 ON -(A$="M") -2*(A$="A") -3*(A$="E") -4*(A$="L") GOTO 1000,2000,3000,4000 |

530 BEEP: GOTO 510 |

This routine accepts **only** a proper response and directs control accordingly,
obviating some lines of ~~error-trapping~~ code in the process.

CALENDAR STUFF

A leap year is any year evenly divisible by 4, excepting the century years not divisible by 400. So 2000 is a leap year, but 1900 and 2100 are not.

A reasonable subroutine for making such a determination might look like this:

430 LEAPYR=0: IF YR MOD 4=0 THEN LEAPYR=1 |

440 IF (YR MOD 100=0) AND (YR MOD 400<>0) THEN LEAPYR=0 |

Compare that with the Boolean equivalent:

430 LEAPYR = (YR MOD 4=0)*((YR MOD 100<>0) + (YR MOD 400=0))

Both routines return 1=yes, 0=no.

To access the number of days in a given month, one has options. For purposes
of this example, M is the month in question, and there is no leap-year adjustment:

70 DIM MO.DAYS(12) |

80 FOR J=1 TO 12: READ MO.DAYS(J): NEXT |

90 DATA 31,28,31,30,31,30,31,31,30,31,30,31 |

Alternatively, one could choose to eliminate the array by setting a variable (or function) thusly:

MO.DAYS = 31 +(M=4 OR M=6 OR M=9 OR M=11) +3*(M=2)

This also could be coded as:

MO.DAYS = 31 +(M=4) +(M=6) +(M=9) +(M=11) +3*(M=2)

A discussion of Booleans is not complete without an acknowledgement of the
downside. In fact, Booleans run **slower** than
**IF..THEN ** statements. Convenient though
they may be, math calculations require more CPU time than logic functions.
In most programming situations, the time differential is unnoticeable; however,
the programmer should avoid the use of Booleans in multiple-loop structures
where speed is critical.

Also, don't plan on having a colleague proofread your code, unless he/she also has been assimilated into the Boolean fold!

To close out this section, I would like to share one last tricky function call,
which won me a monthly prize from a trade magazine. ~~C-64~~ BASIC had
nothing resembling a 'PRINT USING' statement (the entire operating system was only
8k in size!), so data had to be organized for printout in some other way.
I doubt whether you are still programming a Commodore, but if you simply are weary
of formatting PRINT USING statements, you might enjoy this function that aligns
numerical input around the decimal point, irrespective of the size of the numbers:

30 DEF FNUSING(X) = INT(LOG(ABS(X)-(ABS(X)<1))/LOG(10)) +(ABS(X)<1) -(X=0 OR X=1000)

This scary-looking formula merely determines the number of characters that are to the left of the decimal point, by exploiting the idiosyncrasies of the LOG function. This example will print any number with the decimal point aligned at Column 20:

660 PRINT TAB(20-FNUSING(NUM)); NUM

Data values are limited to less than 1 million, due to a BASIC anomaly regarding the powers of 1000; larger numbers could be accommodated by augmenting the last term to:

... -(X=0 OR X=1000 OR X=1000000)

In this case, X would have to be defined as double-precision.

MANY PROGRAMMERS STILL DON'T GET IT

When I tried the command PRINT 2=2 to begin
my first-ever programming session, I discovered the most interesting feature of the
BASIC language. I prompty shared this find with my ~~like-minded~~ brother,
who now uses Booleans religiously in his own programs.

On the other hand, discussions with several university math instructors
didn't fare as well. I was amazed by the nearly universal ignorance of the
true capabilities of Boolean math, even though equivalent constructs are valid
in certain other programming languages and on **any** spreadsheet (but be aware
that they mostly use ~~True = +1)!~~ One professor even claimed that "That
isn't BASIC", but his ~~face-saving~~ edict was erroneous. If the
interpreter/compiler doesn't complain, then the syntax is valid by default, whether in
BASIC or any other programming language.

Actually, there **are** other folks familiar with ~~Booleans —~~ or at
least, there were. For ~~Commodore-64~~ users, every byte of ram was so
precious that **no** spaces were required in program code! Because their usage
saved a lot of bytes, Boolean constructs were discussed regularly in the ~~C-64~~
trade journals; unfortunately, many correspondents admitted that they simply couldn't
understand them.

On the modern front, I recently viewed a German web page detailing some tricks for speeding up Visual BASIC programs. One example was the design of this simple function:

Private Function Comp(a$, b$) as Boolean |

If a$ > b$ Then Comp = True Else Comp = False |

End Function |

The article correctly pointed out that not only is the **ELSE**
clause redundant, but a simpler, faster construct is available:

Private Function Comp(a$, b$) as Boolean |

Comp = a$ > b$ |

End Function |

The difference between those two calls:

70 IF A$ > B$ THEN COMP = 1 ELSE COMP = 0

as compared to the Boolean equivalent,

70 COMP = -(A$>B$)

Another cited VB shortcut is an inherently Boolean concept. The following statement contains a redundancy; yet one sees this sort of code all too frequently:

IF Z<>0 THEN ... {so and so}

A numeric variable equal to zero is logically False. That is the definition of
~~False —~~ having no value. The same applies to string variables: a null
string is False. In all cases, a value of any kind renders a variable True by
default. Therefore,

IF Z THEN ... {this and that}

is perfectly valid, and it runs faster to boot. Variable Z is evaluated; if it exists (has a value), then it is True, and the next portion of the statement is executed. The interpreter/compiler knows the rules of symbolic logic; it doesn't need to be reminded that something with a value is not equal to zero.

The primary point is this: the fact that such instructional pages exist indicates
that even many ~~modern-day~~ programmers are largely ignorant of the Boolean
Mystique. Perhaps this condition is the result of yet another federal conspiracy,
or perhaps some programmers need to have their auras recharged.

I hope that you have enjoyed this introduction to the mysteriously beautiful, yet highly efficient world of Boolean math. Feedback is welcomed.