AT9 — Correctness vs. Performance
The truth table gives you correctness. Full truth-table testing guarantees the function is correct for all inputs. The cost is 2ⁿ test cases.
For n=3, correctness is cheap. For n=32, correctness via exhaustion is impractical. You choose between:
No engineering choice eliminates this tension. The tools available are:
Reduce n. Fewer boolean parameters means fewer combinations. Functions with many boolean flags often have implicit parameter coupling that can be expressed as enums. An enum with 4 values is one variable with 4 states — not 4 boolean variables with 16 combinations.
Formal methods. Model checkers and SMT solvers reason over all combinations without enumerating them. They trade compute time for theoretical completeness. For functions with 50 boolean inputs, a SAT solver might determine satisfiability of a property in milliseconds.
Property-based testing. Tools like Hypothesis (Python) generate random inputs from the input domain, then search for failing cases. This is not 2ⁿ coverage, but it explores the space more broadly than manual tests.
Accept partial coverage. For most production software, this is the actual choice. Document which combinations are tested. Design the function to minimize the impact of untested edge cases.
The AT9 tradeoff is always present. Making it explicit forces a deliberate decision about which corners of the truth table are important.
# AT9 illustration: reduce parameter count by replacing booleans with enum
from enum import Enum
class AccessLevel(Enum):
# Instead of 3 booleans (is_admin, is_editor, is_viewer) = 8 combinations
# Use one enum = 4 states, clearly ordered
ADMIN = "admin"
EDITOR = "editor"
VIEWER = "viewer"
NONE = "none"
def can_edit(access: AccessLevel) -> bool:
# 4 cases instead of 8 combinations — truth table is 4 rows
return access in (AccessLevel.ADMIN, AccessLevel.EDITOR)