Boolean Algebra in Machine Learning

The algebra of true and false: a few laws that simplify tangled conditions, sitting behind every filter, mask and decision rule you write.

De Morgan turns not A and B into not A or not B: the shaded overlap outside both circles is identical on both sides

Why Does This Exist?

Every data pipeline is full of conditions: keep rows where the user is active and not a bot, mask attention positions that are padding or future, alert when deployed and not monitored. Written naively these conditions sprawl across lines, repeat themselves and hide contradictions. Boolean algebra is the simplification engine: a small set of laws that rewrite any tangle of and, or and not into something shorter and obviously correct.

It also names the boundary with logic. Propositional logic is about what follows from what; truth tables check claims row by row. Boolean algebra is the manipulative middle: given an expression, rewrite it. The three pages together cover how conditions mean, how they verify and how they simplify.

The one idea you need first

A Boolean value is either true (1) or false (0). And ( $\land$ ) is true only when both sides hold, or ( $\lor$ ) when at least one holds, not ( $\lnot$ ) flips the value. Note that or is inclusive: true-or-true is true, which surprises people coming from everyday "either-or" speech.

Think of It Like This

Two overlapping sieves

Shake sand through two overlapping circular sieves, A and B. Some grains pass A only, some B only, some both, some neither.

"Kept by A and B" is the overlap lens in the middle. "Kept by A or B" is everything under either rim. "Not kept" is the sand outside both. De Morgan's law is a physical fact about the sieves: the grains rejected by both sieves (not A and not B) are exactly the grains outside the combined outline (not (A or B)). Two descriptions, one pile of sand.

The analogy stops at more than a few sieves: Venn pictures collapse past three sets, while the algebra keeps working for any number of conditions.

How It Actually Works

The laws, each with its plain meaning:

Commutativity, associativity: order and grouping of and/or do not matter. Regroup freely.
Distributivity: $A \land (B \lor C) = (A \land B) \lor (A \land C)$ , and the same with the operators swapped. Factoring conditions in and out.
Identity, annihilator: $A \lor 0 = A$ , $A \land 1 = A$ , $A \lor 1 = 1$ , $A \land 0 = 0$ . Tautologies and contradictions absorb.
Complement: $A \lor \lnot A = 1$ , $A \land \lnot A = 0$ . A claim plus its negation covers everything or nothing.
De Morgan: $\lnot(A \land B) = \lnot A \lor \lnot B$ and $\lnot(A \lor B) = \lnot A \land \lnot B$ . Pushing a not through a gate flips the gate.
Absorption: $A \lor (A \land B) = A$ . The longer clause adds nothing.

Worked example

Simplify $(A \land B) \lor (A \land \lnot B)$ :

(A \land B) \lor (A \land \lnot B) = A \land (B \lor \lnot B) = A \land 1 = A

First distributivity factors out $A$ , then complement collapses $B \lor \lnot B$ to true, then identity drops it. Check against the four rows: when $A$ is true both sides are true regardless of $B$ ; when $A$ is false both sides are false. Four rows agree, so the rewrite is exact, and a two-gate condition became one variable.

Code

The point is the check: verify a simplification against all four input rows instead of trusting the algebra.

1import itertools2
3
4def holds_a_and_b(a: bool, b: bool) -> bool:5    return (a and b) or (a and (not b))  # original tangle6
7
8print(all(holds_a_and_b(a, b) == a for a, b in itertools.product([False, True], repeat=2)))  # -> True

Every row agrees with plain $A$ , so the simplification is proven for all inputs. Extend the same pattern to De Morgan: compare not (a and b) with (not a) or (not b) over the product and it also returns True.

Watch Out For

Reading or as exclusive

In-boolean or, True or True is True. A filter for "flagged or reviewed" keeps items that are both, which surprises people who meant "one but not the other". Exclusive-or needs spelling out: (A or B) and not (A and B). Whenever a product rule says "either", check whether the both-case should pass before coding the inclusive default.

Forgetting precedence: not binds tightest, then and, then or

not A or B parses as (not A) or B, not not (A or B). Dropping parentheses around a negated group silently changes which rows pass, and the bug survives code review because both readings look plausible. Parenthesise every mixed expression even when the precedence table says you could skip it.

The Quick Version

Boolean algebra rewrites tangled and, or and not conditions into shorter equivalent ones.
De Morgan pushes negation through a gate and flips it: not (A and B) is (not A) or (not B).
Or is inclusive: true-or-true is true, so exclusive-or must be spelled out.
Precedence runs not, then and, then or; parenthesise mixed expressions anyway.
Four-row checks prove small simplifications exactly, no trust required.