Most search engines offer at least four ways to perform your search. Enter a few words, and then select
The first three are pretty easy to figure out. The fourth, if you're familiar with computer programming, should be easy to figure out. But if you're new to web design or just beginning to venture into more complex coding involving scripting languages like JavaScript or VBScript (used to create Active Server Pages) you'll benefit from a basic understanding of this Boolean thing.
This article isn't intended to be an exhaustive discussion of the rules of logic, but rather, an introduction to to the terminology and concepts necessary to include logic in your web applications, for instance, in your form validation. I'll also explain why the other choices in our Internet search above are also Boolean.
George Boole was a British mathematician who lived during the 19th century. Despite Boole's never having a formal university education, he showed such insight in mathematics that, at the age of 34 he was appointed to the chair of mathematics at Queens College, Cork, Ireland where he taught for the rest of his life, earning a reputation as an outstanding educator.
At the age of 39 Boole published "An investigation into the Laws of Thought, on Which are founded the Mathematical Theories of Logic and Probabilities" in which he introduced 'Boolean algebra.' In it he reduced the concepts of logic to a simple algebra, mimicking the algebraic functions of mathematics. This work provided the fundaments of the field of logic, and the basis of electronic circuits and computer function.
In building web applications, once we accept input from outside sources (visitors or other applications) we probably want to verify that input. This frequently requires verifying whether certain input matches one or more criteria, or ensuring that it does not match one or more criteria.
For instance: Does the email address the user provided seem to be wellformed? Do we ship to this zip code? Is this user authorized to access that information?
Matching only one condition is simple; if the condition is true, the statement is true, if the condition is false, it's false. It's when we get into multiple conditions that logic becomes slightly more complex.
Remember memorizing your multiplication tables? You could figure out that 11 x 11 = 121, but it's easier to memorize it. Boolean algebra, or logic, can be boiled down to the simplicity of memorized tables as well. Don't worry; I'll explain it in plain English, too.
Although there are many types of logical functions (with odd names like NAND
and XOR
), in our elementary scripting, we'll most likely use only AND
and OR
. The tables below show the logical results of two conditions which can be either TRUE
or FALSE
, and the results when we connect them using AND
and OR
.


So what does it all mean? First, we'll translate the tables into English. Then, we'll see how they would apply in a simplified real–world situation.
The AND
table illustrates the fact that, when we ask "Does the input match Condition 1 AND Condition 2?" the only time the answer is 'yes' is if both Condition 1 and Condition 2 are true. If either one is false, our answer is 'no'; that is, the whole statement is false. AND
functions result in fewer qualifying responses.
The OR
table shows that, when we ask "Does the input match Condition 1 OR Condition 2?" the answer is 'yes' every time, unless both Condition 1 and Condition 2 are false. If either one is true, our answer is 'yes'; that is, the whole statement is true. OR
functions result in more qualifying responses.
Let's say we're giving free shipping on some of our orders. In the first scenario, shipping is free only if the order is over one hundred fins AND
the ship to address is inside Florin, our home country. In this case, we've restricted our results by demanding that both criteria be met.
Possible pseudo–code might look like this:
if ((TotalCost > 100 fins) AND (ShipToCountry = 'Florin')) then ShipCost = 0
Next month, we're feeling generous (or perhaps sales didn't jump as much as we hoped when we introduced free shipping.) Anyway, we've decided to give free shipping if the order totals over one hundred fins OR
the ship to address is in Florin. By allowing either criterion to be met, we've relaxed our results to include a broader range of potential recipients.
Possible pseudo–code might look like this:
if ((TotalCost > 100 fins) OR (ShipToCountry = 'Florin')) then ShipCost = 0
Armed with this knowledge, we can see that 'Any of these words' is just an OR
function, and 'All of these words' is an AND
function. 'This exact phrase' as Boolean logic is slightly more complex than we have room to go into in this article.
That's all fine if we want to verify that our input matches the two criteria. But what if we want to ensure that it doesn't match them? In a slightly modified scenario, let's imagine we're NOT offering free shipping at home in Florin, and we're not offering it to our neighboring country of Guilder, either. Everybody else, however, gets free shipping. So, if the ship to address isn't in Florin or Guilder, they win.
Boolean logic, as it's applied in electronic circuitry, has nifty functions called NAND
and NOR
(among others.) I won't go into much detail except to state that the 'N' at the beginning means 'NOT.' These 'truth tables' (the diagrams we used above) are created by taking the AND
and OR
tables above and simply reversing all the output values. Sounds like a simple solution, right? If we want to make sure we're not matching this OR that, just use something like this bit of pseudo–code:
if (NOT(ShipToCountry = 'Florin') OR NOT(ShipToCountry = 'Guilder')) then ShipCost = 0
We just gave away a lot of free shipping. Here's why: hand me an order; any order. Is the shipping address NOT in Florin? No, it is in Florin? It fails this criterion; no free shipping. But wait; let's analyze the second criterion. Is the shipping address NOT in Guilder? Sure is; NOT in Guilder, I mean. So, since an OR statement only requires one of the criteria to resolve to TRUE, this order gets free shipping.
And, because every single location on earth is either NOT Florin or NOT Guilder (or maybe, NOT both) every single order gets free shipping.
Here's what we want: negate each condition, and connect them with an AND
statement:
if (NOT(ShipToCountry = 'Florin') AND NOT(ShipToCountry = 'Guilder')) then ShipCost = 0
or, to more closely match the NOR
table by creating an OR condition, then negating the whole thing:
if NOT((ShipToCountry = 'Florin') OR (ShipToCountry = 'Guilder')) then ShipCost = 0
You'll probably find it easier to keep track, though, if you aggregate your criteria with AND
s rather than keeping track of the sometimes unexpected results when using OR
s.
Of course, logic isn't always this simple. It's possible to string together more than one AND
with more than one OR
and then throw in some NOT
s just for good measure. For instance, now those nuts in marketing are offering free shipping to anyone NOT in Florin or Guilder, unless they spend more than 100 fins.
Let's take our 'not in either country' bit, and add an OR
to it:
if (NOT(ShipToCountry = 'Florin') AND NOT(ShipToCountry = 'Guilder') OR (TotalCost > 100 fins)) then ShipCost = 0
If you've written some logic using AND
s, OR
s, or both, and the results aren't what you expected, try simplifying. If you're testing multiple criteria simultaneously, try separating them into discrete steps, and outputting the results of each step to the screen. Follow the path, and see where you're getting a TRUE
when you expected FALSE
, or whatever.
Sometimes it helps to simplify the conditions, not just the logic. That's what I did to test the logic in the pseudo–code for this article. Set a few variables equal to 1 for TRUE or 0 for FALSE, and write your logic using simple equations. For instance, if we make x equal 'shipping to Florin', y equal 'shipping to Guilder', and z equal 'total is over 100 fins', we could write the bit above thus:
if (NOT(x = 1) AND NOT(y = 1) OR (z = 1) then RESULT = TRUE
To test each combination, set x = 1 for an order shipping to Florin, or 0 for an order shipping elsewhere. Follow the same logic for y (Guilder) and z (over or under 100 fins), and you can test all six possibilities pretty quickly, verifying that your logic is, well, logical.
Yes, in this scenario, there are only six possible cases. How do we know that? I'm not telling. We'll cover permutations and factorials some other time.