A combined condition keeps 6,120 rows and its complement keeps 3,720, out of 10,000. Where did the other 160 rows go?
answer
- the two branches do not sum
- a third outcome, neither true nor false
- negating undecided leaves it undecided
- three resolutions, chosen by the design
- assert kept plus excluded equals total
basics
~20 sSome rows had a third outcome, neither true nor false, in one of the two conditions, and the combination carried it through. A restriction that keeps only definitely-true rows drops them from the condition and from its complement alike, so the two counts do not sum.
solid answer
~50 sA condition column can hold a third outcome where the value it was computed from said nothing — a row whose input carried the absent marker, meaning whatever the column uses to say there is no value here. Combining two conditions has to decide what that third outcome does, and designs differ. Some carry it through, so the combined outcome is undecided; a restriction then keeps only definitely-true rows, and negating the condition does not rescue them, because the negation of undecided is still undecided. Some settle it at the point of selection by treating undecided as not matching, in which case the counts do sum, but every row you know nothing about has been silently counted as a non-match. Some refuse outright and raise rather than address rows with an undecided outcome. The habit that catches all three is arithmetic: assert that the kept branch and the excluded branch account for every input row before reporting anything computed from either.
go deeper
Recall that a condition can have an outcome that is neither true nor false, and that when it does, keeping the matching rows and keeping the rest will not add up to the number of rows you started with.
Explain what the combination does with a third outcome and why negation does not recover those rows, and name the resolutions that differ between designs rather than asserting the one you have used.
Show the diagnostic instinct: add the two branch counts before trusting either, count the undecided rows when they fall short, and say which population the reported rate was actually computed over.
Decide and document how undecided outcomes are resolved for reported figures across a codebase, because three defensible resolutions produce three different published numbers and the code currently records which one by accident.
## Start from the arithmetic 6,120 plus 3,720 is 9,840. The table had 10,000 rows. A condition and its complement are supposed to be exhaustive, so the missing 160 is not a rounding artefact — it is a message. **A condition and its complement partition the rows only where every outcome is definitely true or definitely false.** Wherever a third outcome exists, they do not, and the gap is exactly the count of rows that had one. This is the cheapest diagnostic in the whole subject, and it is almost never run. ## Where a third outcome comes from A condition column carries one outcome per row. For most rows that outcome is true or false. For some it is neither, because the comparison that produced it was asked about a value that was not there — a row carrying the **absent marker**, meaning whatever that column uses to record that it holds no value. A comparison against nothing has no honest answer, and designs that model this faithfully record a third outcome rather than inventing one. What matters for combining is not how absence is represented — that varies widely — but that the condition column reaching the connective may hold three kinds of outcome, not two. ## What combining does with it There are three broad resolutions in use, and a question that assumes one of them is wrong for a reader working in another: | resolution | what the combination produces | what the counts do | |---|---|---| | Carry it through | undecided wherever either side is undecided | branch and complement both drop those rows; the counts fall short | | Settle at selection | undecided is treated as not matching when rows are addressed | the counts sum, and undecided rows sit in the excluded branch | | Refuse | an error when an undecided outcome is used to address rows | nothing runs, and you find out immediately | Within the first family there is a refinement worth knowing: some designs let the decisive side settle the combination even when the other is undecided, on the reasoning that a definite false conjoined with anything is false, and a definite true disjoined with anything is true. Under that rule only the genuinely undecidable rows stay undecided, and the gap is smaller than the raw count of rows with an absent input — but it is still a gap. ## Why the complement does not rescue the rows The instinct on seeing 6,120 is to compute the opposite condition and expect 3,880. It comes back 3,720 because negation is element-wise too, and the negation of undecided is undecided, not true. The 160 rows are excluded from both branches by the same mechanism. Chaining a third condition does not help either; undecided spreads rather than resolving. ## Why a rate is the real casualty Nobody reports row counts. They report something computed from them — a share, a conversion rate, a pass rate. Consider what the two branches were for: - If the rate is computed as *kept divided by the input total*, the undecided rows are in the denominator and count against you, which is defensible but should be a decision. - If it is computed as *kept divided by kept plus excluded*, the undecided rows have silently left the population altogether, and the rate is over a sample you did not choose. - If the design settles undecided as not matching, the rate is over the full population but every unknown row has been asserted to be a non-match, which biases it in one direction by construction. Three defensible numbers, three different values, and nothing in the code says which one you produced. This is why the resolution has to be stated rather than inherited. ## The check 1. **Assert the partition.** After splitting on a combined condition, assert that the kept count plus the excluded count equals the input row count. One line, and it fires on exactly the failure described here. 2. **Count the undecided rows directly** when it does not hold, and treat that count as a data quality figure rather than a nuisance. 3. **State the resolution in the code that reports the number**, so a reader knows whether an undecided row was counted as a non-match, excluded from the population, or refused. 4. **Never infer the resolution from one run.** A table whose inputs happen to be complete will partition perfectly under all three designs, and the difference appears only on the day the data has a hole in it — which is to say, in production.
- Why does negating the combined condition not bring the 160 rows back?Negation is element-wise as well, and the negation of an undecided outcome is still undecided. Both branches therefore exclude the same rows for the same reason. Chaining further conditions spreads the undecided outcome rather than resolving it, so no amount of additional logic recovers them.
- If the two branch counts do sum to the total, does that prove there were no undecided outcomes?No. It is equally consistent with a design that settles undecided as not matching when addressing rows, which puts every unknown row in the excluded branch. The counts sum perfectly and a whole class of rows has been asserted to be non-matches. Count the undecided outcomes directly rather than inferring from the sum.
- Which denominator should a rate computed from the two branches use?Whichever one you can defend out loud. Dividing by the input total counts undecided rows against the rate; dividing by kept plus excluded quietly removes them from the population. Both are legitimate, neither is a default, and the code that reports the figure should say which it used.
saying these in an interview costs you the question
- Assumes a condition and its complement always partition every row.
- Reads the missing rows as a defect in the restriction step.
- Believes every design treats an undecided outcome as a non-match.
- Computes a rate from the two branches without checking they sum.
- Thinks negating the condition recovers the rows that were dropped.
- Says a single clean run proves the data has no undecided outcomes.