Logical Operators

AND

P AND Q is True if and only if both P is True and Q is True. One False operand makes the whole expression False.

In programming: if user.is_authenticated and user.has_permission("write"): — access is granted only when both conditions hold.

OR

P OR Q is True if at least one of P, Q is True. Both can be True simultaneously. This is inclusive OR — it includes the case where both are True.

In programming: if request.is_cached or fallback_available: — service continues if either condition holds.

NOT

NOT is unary — it takes one operand and inverts its truth value. True becomes False; False becomes True.

In programming: if not user.is_banned: — the inverse of the stored condition.

XOR

XOR is True when exactly one operand is True. It is False when both are True and False when both are False. XOR is less common in high-level boolean logic, but it appears in:

• Cryptography: bitwise XOR for key mixing and encryption
• Error detection: parity bits in RAID-5 are computed with XOR
• Toggle logic: state = state XOR True flips a boolean without an if-statement

# XOR implemented in Python (Python has no boolean XOR keyword, use !=)
def xor(p: bool, q: bool) -> bool:
    # XOR: exactly one of p, q must be True
    return p != q

# Alternatively, explicit:
def xor_explicit(p: bool, q: bool) -> bool:
    return (p or q) and not (p and q)

De Morgan’s Laws

De Morgan’s Laws are the most important identities in boolean algebra for working programmers.

Law 1: NOT (P AND Q) = (NOT P) OR (NOT Q)

Law 2: NOT (P OR Q) = (NOT P) AND (NOT Q)

In plain language:

• To negate a conjunction, distribute the negation and change AND to OR.
• To negate a disjunction, distribute the negation and change OR to AND.

The transformation is symmetric. If you negate the result of applying the law, you get back the original.

Why this matters in code:

Programmers frequently write conditions as negative checks. “Don’t allow if suspended or banned.” In code:

# Version A: direct negation of compound condition
if not (user.is_suspended or user.is_banned):
    allow_access()

# Version B: De Morgan's applied manually
if not user.is_suspended and not user.is_banned:
    allow_access()

These are equivalent. A and B evaluate identically for every combination of is_suspended and is_banned. You can verify this with a truth table (Chapter 3 will formalize this). For now, trust the law and verify with a few cases:

Identical. The laws are correct.

Where De Morgan’s fails programmers:

The failure is not in the law. The law is provably correct. The failure is in applying the law incorrectly while refactoring.

Consider the payments bug from the opening hook. The original condition was computed as:

is_suspended = account_frozen and payment_blocked  # True only when BOTH hold

The authorization check was:

if not is_suspended:  # allow if NOT (frozen AND blocked)
    # By De Morgan: allow if (NOT frozen) OR (NOT blocked)
    # This is True for almost everyone
    process_payment()

The developer changed is_suspended to account_frozen or payment_blocked, intending to catch either condition. Now:

is_suspended = account_frozen or payment_blocked  # True if EITHER holds

But the authorization check still reads not is_suspended, which now means NOT (frozen OR blocked), which by De Morgan’s equals (NOT frozen) AND (NOT blocked). This is stricter than before: only accounts that are neither frozen nor blocked can process payments. That stricter behavior may well be what the developer intended for the new policy, but it is not what callers expected. Code written against the old definition of is_suspended (AND semantics, permissive) now silently operates under the new definition (OR semantics, strict). The real failure is that the intermediate variable changed meaning without any visible signal — its name, type, and call site all remained identical. The contract (FM8) broke without an error being raised. Any system that depended on the old behavior — including callers that deliberately relied on frozen-but-not-blocked accounts being allowed through — now behaves differently, silently and immediately.

# Safer pattern: name the authorization condition explicitly
def can_process_payment(account_frozen: bool, payment_blocked: bool) -> bool:
    # Explicit statement: account is usable for payments
    # Named conditions prevent silent semantic drift
    account_is_usable = not account_frozen and not payment_blocked
    return account_is_usable

By naming the terminal condition, you eliminate the intermediate is_suspended variable and the implicit De Morgan inversion.

Short-Circuit Evaluation

Most programming languages implement short-circuit evaluation for AND and OR. This is a performance and safety optimization derived from the truth table structure.

Short-circuit AND:

If the left operand of P AND Q is False, the whole expression is False. The right operand does not need to be evaluated. Python, Java, C, JavaScript — all short-circuit AND.

def get_user_role(user_id: int, db) -> str | None:
    # Short-circuit AND: if user_id is falsy, db.get() is never called
    # This prevents a database call with an invalid ID
    user = user_id and db.get_user(user_id)
    return user.role if user else None

# More common pattern: guard clause using short-circuit
def process(items: list, transform) -> list:
    # If items is empty, transform is never called
    return items and [transform(item) for item in items]

Short-circuit OR:

If the left operand of P OR Q is True, the whole expression is True. The right operand is not evaluated.

def get_config_value(key: str) -> str:
    # Short-circuit OR: use cached value if available, otherwise fetch
    # fetch_from_remote() is only called if cache returns None/falsy
    return config_cache.get(key) or fetch_from_remote(key)

Implications for side effects:

Short-circuit evaluation means the right operand might not run. If the right operand has side effects — increments a counter, logs a message, modifies state — those side effects are conditional on the left operand’s value.

# Dangerous: side effect in right operand
# record_attempt() may or may not run depending on is_enabled
if is_enabled and record_attempt(user_id):
    grant_access()

If is_enabled is False, record_attempt is never called. If audit logging is required for all access attempts (including denied ones), this code silently skips the log. This is FM11 (Observability Blindness) in miniature — the system fails to record events it should be recording.

Non-short-circuit evaluation:

When you need both operands to evaluate regardless of the first, avoid compound boolean expressions with side-effectful operands. Call each function separately and store the result:

# Safe: both functions always called
attempt_recorded = record_attempt(user_id)    # always runs
is_enabled = check_enabled(user_id)            # always runs

if is_enabled and attempt_recorded:
    grant_access()

Operator Precedence

In code, NOT binds tighter than AND, which binds tighter than OR. This matches mathematical convention.

NOT > AND > OR

not a or b and c parses as (not a) or (b and c).

Explicit parentheses eliminate ambiguity. The recommendation is simple: parenthesize compound conditions. The performance cost is zero. The readability cost is zero. The correctness benefit is real.

# Ambiguous: relies on precedence knowledge
if not is_suspended or has_override and is_premium:
    ...

# Unambiguous: explicit structure
if (not is_suspended) or (has_override and is_premium):
    ...

Truth Table Preview

Each operator’s behavior is fully captured by a 2-variable truth table. Chapter 3 builds these systematically. For reference:

P     Q     P AND Q   P OR Q   NOT P   P XOR Q
True  True  True      True     False   False
True  False False     True     False   True
False True  False     True     True    True
False False False     False    True    False

Level 1 — Understand

1. Apply De Morgan’s Law to simplify each expression. Show each step.
   • NOT (user_is_admin OR user_is_owner)
   • NOT (request_is_valid AND session_is_active AND rate_not_exceeded)
   • NOT (NOT a AND NOT b)
2. Given P = True and Q = False, evaluate:
   • P AND Q
   • P OR Q
   • NOT P OR Q
   • NOT (P AND NOT Q)
   • P XOR Q
3. What is short-circuit evaluation? Give one situation where it prevents a bug and one situation where it introduces a bug.

Level 2 — Apply

A rate limiter has this condition:

def should_allow(request_count: int, limit: int, has_premium: bool, is_admin: bool) -> bool:
    return (request_count < limit or has_premium) and not is_admin

1. The developer meant: “allow if under limit or premium, but always block admins (they use a separate endpoint).” Is the code correct? Evaluate for request_count=100, limit=50, has_premium=False, is_admin=False.

2. A new requirement: “never block if admin.” The developer changes not is_admin to is_admin. Evaluate the same inputs. What changed?

3. The actual requirement is: “allow if under limit OR has_premium, regardless of admin status — admin is handled elsewhere.” Rewrite the function to match this intent and remove the admin check entirely. Name the AT3 tradeoff involved.

Level 3 — Design

An e-commerce platform has this access rule, stated in English:

“A user can modify an order if they placed the order and the order is not yet shipped, OR if they are a support agent and the order has an open dispute, OR if they are an admin.”

1. Identify every atomic statement in this rule.

2. Write a Python function can_modify_order(user, order) -> bool using named boolean variables for each atomic statement.

3. Write the De Morgan’s-equivalent formulation of the first clause only: “(placed the order) AND (not yet shipped)”. What does the De Morgan’s form express in plain language? Is it useful?

4. Suppose the rule is enforced on both the frontend (React) and backend (Python API). Identify two specific ways FM4 (Data Consistency Failure) can occur, and propose a mitigation that uses the AT8 (Coupling vs. Cohesion) tradeoff explicitly.

A complete answer will: define the chosen approach, quantify its cost or complexity, and identify what breaks first as scale or load increases.