4.5 POS: Product of Sums

Define Product-of-Sums (POS) form, identify its internal OR/external AND structure, and recognize that SOP and POS are two structurally different representations of the same underlying function.

Product of Sums (POS) is the structural mirror image of SOP: instead of ORing together AND terms, a POS expression ANDs together OR terms. Each individual factor is a sum (OR) of some subset of the function's variables (or their complements), and the overall function is the product (AND, in Boolean terminology) of all those sum-factors. POS matters for exactly the same reason SOP does — it is not just an alternative notation but a distinct hardware structure (an OR-plane feeding an AND-plane) and the natural output form of maxterm-based (Module 4.7) and K-map-based zero-grouping analysis, used whenever a function is more naturally described by its false (0) conditions rather than its true (1) conditions.

Core Concept: Sums Multiplied Together

The spec defines POS directly: 'Product of Sums' — F = (A+B)(A'+C)(B+C'). Each individual factor in this expression — (A+B), (A'+C), (B+C') — is a sum term, meaning its variables are combined internally using OR; the overall expression then combines those sum terms using AND, which in Boolean terminology is called a 'product'. This is where the name comes from: a product (AND) of sums (OR terms) — the exact structural inverse of SOP's sum of products.

Just as SOP has a precise internal/external rule, POS has its own precise mirror-image rule: each factor is ORed internally, and the factors are ANDed together. This two-level structure — OR within a factor, AND across factors — is the defining characteristic of POS form, regardless of how many variables a specific factor contains or how many total factors the expression has.

• POS = Product of Sums: several OR (sum) factors combined by AND (product). • Spec example: F = (A+B)(A'+C)(B+C') — three sum factors, ANDed together. • Structural rule (mirroring SOP): each factor is ORed internally, and the factors are ANDed. • A sum factor can include any subset of the function's variables, in true or complemented form.

Step-by-Step: Recognizing POS and Relating It to SOP

To check whether an expression is in POS form, scan its top-level structure: if the outermost operator combining the expression's major pieces is AND, and each of those pieces is itself a pure OR factor (with no AND nested inside any individual factor), the expression is in POS form. The spec's example passes this check directly: the top-level operator combining the three parenthesized groups is AND (implied by their juxtaposition), and each group — (A+B), (A'+C), (B+C') — is a pure OR factor.

The spec's tricky point makes an essential conceptual link explicit: SOP and POS are structurally different representations of the same Boolean function. This means that for any given truth table, there exists both an SOP expression and a POS expression that compute the identical function — they will look nothing alike syntactically (one built from ANDed variables OR'd together, the other from ORed variables ANDed together), and yet, evaluated on every possible input row, they produce exactly the same outputs. Choosing SOP versus POS for a given function is a structural/hardware decision, not a question of which one is 'more correct'.

• Step 1: Check the top-level operator combining the major pieces — AND means the expression is a candidate for POS. • Step 2: Check that each individual piece is a pure OR factor with no nested AND. • Step 3: Recall the spec's tricky point: SOP and POS can represent the exact same function despite looking completely different.

Practical and Real-World Application: When POS Is the Natural Choice

POS form maps onto the mirror-image two-level circuit structure from SOP: a layer of OR gates (one per sum factor), each feeding into a single AND gate that combines all the sum factors into the final output. This OR-plane-then-AND-plane structure is used in certain programmable logic architectures and is the natural target form when a function's maxterm expansion (Module 4.7) is more compact than its minterm expansion — precisely when a function is 0 for very few input combinations, making it more economical to describe those few 0-conditions (as maxterms/POS) than to describe the many 1-conditions (as minterms/SOP).

This SOP-versus-POS choice is a concrete design decision K-maps make explicit: grouping the 1-cells on a K-map yields a minimized SOP expression, while grouping the 0-cells on the very same K-map yields a minimized POS expression for the identical function — Module 5's don't-care and minimization coverage builds directly on being able to recognize and choose between these two forms.

Common Mistake and the Tricky Concept

The most common mistake is assuming SOP and POS expressions for the 'same' function must look similar, or trying to convert one into the other by superficial pattern-matching (like just swapping every + for a · and vice versa across the whole expression) — that naive swap does not, in general, produce an equivalent expression. Correctly converting between SOP and POS requires either full algebraic manipulation (using the distributive law and De Morgan's laws together) or working back through the truth table (via minterms and maxterms, Modules 4.6–4.8), not a symbol-for-symbol substitution.

A second trap is treating a factor with a single variable, like a hypothetical (A) on its own, as automatically disqualifying an expression from POS form — a 'sum' of one term is a degenerate but still valid OR factor (a single-variable OR 'sum' trivially equals that variable), so an expression like F = A(B+C) does technically have a valid POS-style first factor (A alone); what makes the overall expression not proper two-level POS is a different structural issue (in this case, only two factors total with mismatched forms) that should be checked carefully rather than assumed from a single factor's shape.

POS Structural Pattern

'Product' means AND, and 'sum' means OR — Boolean-algebra terminology, mirroring SOP's naming exactly in reverse. A factor is only a valid POS 'sum' if it contains no internal AND.

Product of Sums (POS):
  F = (factor1)(factor2)(factor3)...
  where each factorN is a pure OR (sum) of variables/complements

Spec example:
  F = (A+B)(A'+C)(B+C')
       └─┬─┘└──┬──┘└──┬──┘
        sum     sum     sum    — all three ANDed (multiplied) together

Code Examples

This is the spec's own POS example. Each of the three parenthesized factors is a pure OR combination of (possibly complemented) variables, with no AND inside any individual factor, and the overall function ANDs all three factors together — the exact mirror image of the SOP structural rule.

F = (A+B)(A'+C)(B+C') — three sum factors multiplied by AND This is the spec's own tricky point made concrete: SOP and POS are structurally different representations, and it is entirely possible for two very different-looking expressions — one all-AND-then-OR, the other all-OR-then-AND — to compute the exact same function once you actually derive the correct pairing from the same truth table.

SOP and POS are structurally different representations of the same Boolean function.

F = (A+B)(A'+C)(B+C')

Sum factor 1: (A+B)     (A OR B)
Sum factor 2: (A'+C)    (A complemented, OR C)
Sum factor 3: (B+C')    (B OR C complemented)

F = factor1 · factor2 · factor3   (all three multiplied via AND)

Function described two structurally different ways:

  SOP form:  F = A'B + BC + AC'      (sum of AND products)
  POS form:  F = (A+B)(A'+C)(B+C')   (product of OR sums)

Both can represent a valid Boolean function; the specific
SOP or POS expression for a GIVEN function must be derived
from its truth table (minterms/maxterms) or by algebraic
conversion — they are not found by symbol-swapping alone.

Important Rules

POS = Product of Sums: AND of OR terms, never the reverse structure.

Each individual factor must be a pure OR (sum) with no AND nested inside it.

The overall expression combines all sum factors using AND ('product').

SOP and POS are structurally different representations of the same Boolean function — never assume one converts to the other by simple symbol-swapping.

OR-Plane/AND-Plane Hardware and Sparse-Zero Functions

POS form maps onto an OR-plane-then-AND-plane two-level circuit structure and is the natural choice when a function's maxterm expansion (few 0-outputs) is more compact than its minterm expansion — exactly the case a K-map's 0-cell grouping (Module 5) is designed to exploit, producing a minimized POS expression directly from the map.

Converting an SOP expression to POS (or vice versa) by simply swapping every + for · and every · for + throughout the whole expression.

Derive the correct corresponding form from the function's actual truth table (via minterms and maxterms) or through full algebraic manipulation using De Morgan's and the distributive law — a naive symbol swap does not produce an equivalent function in general.

The spec's tricky point states SOP and POS are 'structurally different representations of the same Boolean function' — meaning a correct SOP-to-POS conversion requires genuine derivation, not a shortcut substitution that happens to look similar.

[tricky-problem] What does the spec's tricky point about SOP and POS specifically establish? A. SOP and POS are always identical expressions with different variable names. B. SOP and POS are structurally different representations that can nonetheless represent the exact same Boolean function. C. POS expressions cannot be implemented in real hardware. D. SOP is always simpler than POS for any given function.

B. SOP and POS are structurally different representations that can nonetheless represent the exact same Boolean function. — The spec states: 'SOP and POS are structurally different representations of the same Boolean function.' This means two syntactically very different expressions — one built as ANDs summed by OR, the other as ORs multiplied by AND — can, when correctly derived from the same truth table, compute identical outputs for every input combination.

[interview] Structurally, what is the exact relationship between SOP's rule ('AND internally, OR across terms') and POS's rule? A. POS follows the identical rule as SOP with no differences. B. POS is the mirror image: OR internally within each factor, and AND across the factors. C. POS only allows a single variable per factor. D. POS requires every variable to be complemented.

B. POS is the mirror image: OR internally within each factor, and AND across the factors. — SOP combines pure AND (product) terms using OR; POS combines pure OR (sum) factors using AND — an exact structural mirror image, matching the way NAND and NOR mirror AND and OR earlier in Module 3.

A function should output 0 only when (A is false and B is false), and separately output 0 only when (B is false and C is true). Express the corresponding non-zero condition for each case as an OR sum factor, then combine both factors into a POS expression.

Avoiding (A=0,B=0) means the factor (A+B) must hold. Avoiding (B=0,C=1) means the factor (B+C') must hold. Combined: F = (A+B)(B+C') — a two-factor POS expression.

Each 'must not be this 0-condition' translates into a sum factor that is false exactly for that condition and true otherwise.