The total number of possible programs which can be generated from a limited entry table of (n) conditions is given by the formula:

 

    

 

This means that for a simple set of five (y/n) conditions, there are 1,658,880 possible programs. The thought of inspecting all of them by hand to select the optimal generated code should tell you why you need LogicGem.

 

WARNING: LogicGem will attempt to generate code from incomplete or imperfect logic tables. Code generated from such tables will certainly not be correct, much less optimal. Many times it will not have correct syntax and will not compile using a commercial language compiler product.

 

LogicGem cannot understand the semantic content of your code and therefore might generate code which you can optimize further by hand. In particular, you can take a step towards optimization by looking at the lowest or deepest level of nesting in the if/then/else statements for duplicated actions. For example, consider the code fragment:

LogicGem has no way of knowing if the Action module will work the same way when condition Cx is TRUE as it will when Cx is FALSE. It has to take the safest course and generate the full decision structure. As the logic programmer, you should know if Action really needs condition Cx to operate as intended. If it does not care, then this if/then/else statement can be optimized to a single call to the Action module. This sort of code structure usually happens when the user has added a special “error” action to complete the missing actions in a logic table.

 

Another possible optimization in the generated code is where nested if/then/else statements can be replaced by Boolean operators that are supported by the target programming language. For example, consider the code fragment:

LogicGem has no way of knowing if this can be optimized to the following shorter and more concise version with a Boolean AND operator:

In a similar manner, consider the fragment:

This code can often, but not always, be optimized to:

It is worth noting that a good optimizing compiler will convert Boolean expressions into the object code equivalent of the original LogicGem nested if/then/else structures. This is called short circuit evaluation because it arrives at an action with the smallest number of logical tests. A weaker compiler will not do these optimizations, so the original LogicGem generated code will actually run faster than the hand tuned versions.

 

If execution speed is important, you might want to compare the original against a hand tuned version, and then pick the fastest one. If execution speed is not important, hand tuned code might be easier for people to read because it will not have such deeply nested program control structures.

 

There are similar optimizations for case/switch statements. Unfortunately, these are more language dependent For example the Pascal CASE statement differs in structure from the C switch statement.

 

In the final analysis however, the original code resulting from a LogicGem compile of a perfected logic table will always work fine. Optimizations such as those described above are entirely optional.