Creating Truth Tables. A Simple Truth Table for Programming Purposes
May 21st 2009 | David Cooksey
Truth tables are a handy method for quickly listing all the possible combinations for a set of inputs in logic.
Coincidentally, they are also very useful for doing the same thing in programming.
Let’s say you have a function that has 4 Boolean input parameters and you want to be sure it is mock tested with all the possible combinations. You could just eye-ball it, but chances are a combination or two have been forgotten. Enter truth tables!
As we have 4 variables with 2 values each, we know that we have 2^4 = 16 possible combinations. Create a table with 4 columns—one for each variable, and 16 rows—one for each combination. Then fill the table out as shown below. For verisimilitude we are using variable names that could have meaning in code.
US Citizen |
Born In US |
Gender |
Born Before 1950 |
True |
True |
M |
Yes |
True |
True |
M |
No |
True |
True |
F |
Yes |
True |
True |
F |
No |
True |
False |
M |
Yes |
True |
False |
M |
No |
True |
False |
F |
Yes |
True |
False |
F |
No |
False |
True |
M |
Yes |
False |
True |
M |
No |
False |
True |
F |
Yes |
False |
True |
F |
No |
False |
False |
M |
Yes |
False |
False |
M |
No |
False |
False |
F |
Yes |
False |
False |
F |
No |
There is a simple pattern here, though it’s more apparent when using 1s and 0s or Ts and Fs instead of the more realistic data used here. The first variables column is half True and half False. The second is divided into quarters, alternating between True and False. The third column is divided into eighths, and the fourth is divided into sixteenths.
Let’s consider an example with 3 variables. The first variable is a Boolean; the second an enumeration consisting of three items; and the third a date. In this case the date has 4 ranges of data that change how it is treated in code, namely the four centuries between 1700 and 2000—18th, 19th, 20th, 21st.
2 * 3 * 4 = 24 combinations.
Boolean |
Enumeration |
Date (Century) |
T |
Item1 |
18 |
T |
Item1 |
19 |
T |
Item1 |
20 |
T |
Item1 |
21 |
T |
Item2 |
18 |
T |
Item2 |
19 |
T |
Item2 |
20 |
T |
Item2 |
21 |
T |
Item3 |
18 |
T |
Item3 |
19 |
T |
Item3 |
20 |
T |
Item3 |
21 |
F |
Item1 |
18 |
F |
Item1 |
19 |
F |
Item1 |
20 |
F |
Item1 |
21 |
F |
Item2 |
18 |
F |
Item2 |
19 |
F |
Item2 |
20 |
F |
Item2 |
21 |
F |
Item3 |
18 |
F |
Item3 |
19 |
F |
Item3 |
20 |
F |
Item3 |
21 |
This pattern is marginally more complex. When filling out a truth table, start at the right side and rotate through the values going down. For all the columns following, rotate through the valid column values per the number of combinations in the preceding columns.
For example, let’s say you have the centuries laid out and you need to fill in the enumeration column. There are 4 valid values for the century column, so write down Item1 four times, then Item2 four times, etc., until the column is filled. For the Boolean column, there are 4 [century] * 3 [enumeration] = 12 valid combinations, so you write down T twelve times, then F twelve times.
The great thing about this method is that is simple and logical and can be used with any number of variables.
If you don’t use truth tables, how do you check that you have everything covered? Next time you’re programming a new algorithm, sketch out your truth table on paper, then use it to drive your unit tests and make sure you have everything covered.
And an easy way to create a truth table is to create persistent cursors for each dimension with a record for each discrete variation on that dimension. Then do a cartesian join of those cursors, into the truth table. This makes maintenance easier, since dimensions can be sliced and diced differently, as experience with the data possibilities deepens.
Hank Fay
It sure would be great if the truth table could be dynamically generated.
However, if that was the case, with sufficient speed of the algorithm, you might not need the table.
BTW, great concept transfer from boolean logic class.