A logic table is a graphic method for representing, testing, and implementing a process. It builds a set of rules for taking actions based on a set of conditions. The table can then be tested for completeness and correctness, and then used to generate optimal source code for computer programs or documentation for humans.
The part of the logic table where the conditions appear is called the condition stub. The part of the logic table where the actions appear is called the action stub. The condition stub appears on the upper left hand side of the logic table and the action stub appears directly below it.
A logic table made up solely of conditions that have binary (or y/n) values is called a limited entry table. Limited entry tables are the only kind supported by LogicGem. Tables having only conditions with greater than binary values are called extended entry tables. Logic tables that have both binary and greater than binary conditions are called mixed entry tables.
The condition entries appear in columns to the right of the condition stub. These consist of possible values of the condition. Conditions for which any values will do within a rule are read as "don't care" and are shown with dashes in the condition stub.
Conditions which have some relationship among themselves and eliminate certain combinations of conditions are called a dependent condition set. For example, three binary traffic signal conditions (red? (y/n), yellow? (y/n), green? (y/n)), are a dependent condition set because a traffic signal cannot be red, yellow, and green at the same time.
LogicGem cannot determine if a dependent condition set exists in the condition stub. This requires semantic information about the problem which only a human being can provide.
The action entries appear in columns to the right of the action stub. These are whole numbers which give the order of execution of the actions, or blanks which tell you that an action is not performed as a result of this rule.
In some problems, the order of execution is not important and in others it is vital. For example, in a recipe for a cake you can add flour and sugar to a mixing bowl in either order, but you cannot bake the cake before you have mixed the ingredients together. LogicGem uses ordering in the action stub since unordered actions can be simulated by always numbering the actions from top to bottom in their column.
The condition entry and the matching action entry together are called a rule. Rules can be stated in an if/then form; "If all condition entries are all met, then perform all action entries in the given order."
The dashes or "don't care" values in the condition stub of a rule are really a shorthand for a set of rules. A rule without dashes is called a simple rule. A rule with dashes is called a complex rule.
LogicGem needs to expand this shorthand to perform certain checking operations on the table. Expansion is done by the following procedure:
Complex rules which have no simple rules in common are called disjoint. Complex rules which do have one or more simple rules in common are called overlapping. The overlapping rules can cause two problems, redundancy and contradiction, which are collectively referred to as ambiguity.
A redundancy means that the same simple rule was hidden in two or more complex rules. This is not fatal but it wastes space, confuses the user, and will generate less than optimal results.
A contradiction means that two or more simple rules have the same condition entry, but two or more different action entries. This is serious, and must be removed before any valued results can be gotten from the logic table. LogicGem will assume that different actions with the same conditions exclude each other when it reports possible contradictions. This might not actually be the case, but only the logic engineer can determine this. LogicGem has a choice of strategies for removing contradictions, which will be discussed later.
If a table has as many rules represented as the Completion Ratio says it should, and there is no contradiction or redundancy, the table is said to be mechanically perfect. That is, all possible combinations of condition values are accounted for and none can lead to contradictory or redundant action sets. This is the primary goal of LogicGem.