Why does adding a single number to a 1,000-value column behave differently from adding a 3-value operand to it?
answer
- one value versus many
- every rule agrees on the single value
- three against a thousand has no obvious reading
- refuse, repeat, or fill absent
- no error is not proof of a match
basics
~20 sA one-value operand has nothing to disagree about: every rule reuses it at every position, giving 1,000 results. Three values against 1,000 positions is a real size conflict, and designs resolve it differently - by refusing, by repeating, or by filling with absent values.
solid answer
~50 sCombining two operands position by position needs a rule for the case where they hold different numbers of values. That rule decides whether the smaller operand is reused against every position of the larger one, or the pair is refused. A single value is the case every version of the rule agrees on: there is exactly one reading, so you get 1,000 results everywhere. Three values against 1,000 positions is a genuine conflict with no obvious reading, and the designs in this family answer it in materially different ways - one refuses outright, one repeats the shorter operand over the longer (warning rather than stopping when the lengths do not divide evenly), and one does not stretch at all but matches the two operands by their row labels and marks every unmatched position absent. Only the first of those is an error, so "it ran" proves nothing about the sizes.
go deeper
Recall the two cases and keep them apart: one value is reused at every position and always works; more than one value against a different count is a conflict whose outcome depends on the design. Say that out loud and you have passed this question.
Explain the three resolutions and what each one returns for the same written expression - refused, repeated to fill, or matched by row label with absent values where labels did not meet. Name which of the three is actually an error.
Show the operating habit: predict the result's length, assert it right after the expression, and treat a warning as a failed run. Explain why a wrong-length result passes every value-level check you might write.
Frame it as a team rule rather than a personal habit: which size expectations are worth asserting at the boundaries of a shared transform, and what a team pays when the same expression is legal in two tools and means different things in each.
## The question the rule answers When an operation combines two operands **position by position** - one result per position, built from one value on each side - it must first decide what to do when the two sides do not hold the same number of values. **Stretching a smaller operand** is the rule that answers exactly that: it decides whether an operand holding fewer values is reused against every position of the larger one, or whether the pair is refused outright. The borrowed term of art for the reuse is **broadcasting**: the smaller side is treated *as if* it had been repeated until both sides present the same number of positions. Two things make this first-screen material rather than trivia: - the rule is genuinely **not the same** across the tools in this family, and - when a rule declines to stretch, **not every design stops**. ## Why one value is the case every rule agrees on An operand holding exactly one value offers nothing to disagree about. There is only one available reading: use that value at every position of the larger operand. A thousand-value column plus a single number therefore gives a thousand results in every design here - no ordering question, no label question, no length question to get wrong. That is why adding a constant feels like it has no rule behind it at all. It has the same rule; it is simply the case where every version of the rule produces the same answer. Almost everything a candidate finds surprising later comes from assuming that agreement continues once the small side holds more than one value. ## Three against a thousand is a genuine conflict Now the small side holds three values and the large side has a thousand positions. There is no single obvious reading, so each design has to commit to one. | how the design resolves a size conflict | what three values against a thousand gives you | |---|---| | Line the two operands' axis lengths up from the last axis backwards, stretch any axis whose length is one, refuse anything else | Refused. Three is not one, so there is nothing eligible to stretch. | | Repeat the shorter operand over the longer one | A thousand results when the longer length is a whole multiple of the shorter; where it is not, typically a partial fill plus a warning rather than a stop. | | Do not stretch at all - match the two operands by their row labels | A result covering both sets of labels, carrying the absent-value marker at every position where a label was present on only one side. | The **absent-value marker** is whatever a tool stores where there is no value: for some designs a borrowed floating-point sentinel, for others a separate validity bit kept beside a value of the narrow width. Read that table once more with the failure in mind: **only the first row is an error.** The other two hand you a full-length result and let the program continue. ## How the mismatch gets in Size conflicts are rarely typed deliberately. The usual sources are ordinary: - two operands that came from **different filters**, so one lost rows the other kept; - a lookup or an aggregate that **returned fewer rows than the thing it is being combined with**; - a short literal list of thresholds - one per category, say - written against a column of records rather than against a column of categories; - an operand that gained or kept an **extra axis of length one** from the operation that produced it, which makes it eligible to stretch where a flat list would not have been. Each of these looks fine on the line where it is written. The conflict only appears where the two meet. ## What to do about it 1. **Predict the result's length before you run the expression.** If you cannot say how many values should come back, you cannot tell a correct result from a stretched one. 2. **Check the length you got, not the values you got.** Every individual value in a stretched result is an arithmetically correct combination of *some* pair; the count is the only thing that is obviously wrong. 3. **Treat a warning as a failure.** A partial fill that warns is a wrong answer that told you politely, and in a scheduled job nobody is reading that line. 4. **Remember that a single value is always safe.** Anything else deserves a moment's thought about which rule is in play. The junior-level takeaway is not which tool does which. It is that a size mismatch is **not reliably an error**, so the absence of an error message is not evidence that the two sides lined up.
- What exactly makes a one-value operand safe under every one of these rules?It offers only one possible reading. With a single value there is no question of which value goes with which position, no question of order, and no question of labels - so refusing it would serve no purpose. Every design therefore reuses it at every position of the larger operand and returns a result the length of that larger operand.
- If a size mismatch only produces a warning, why is that worse than an error in a scheduled job?Because nothing is watching. An error stops the job and someone looks; a warning goes to an output stream that a scheduler usually discards, while the job finishes successfully and publishes a result built from a partial fill. The remedy is to turn the expectation into an assertion on the result's length, which fails loudly whatever the tool chose to do.
- Two operands hold 1,000 and 500 values. Can that ever succeed?Yes, under a repeat-the-shorter rule, because 1,000 is a whole multiple of 500: the shorter operand is laid down twice and you get 1,000 results. Under a rule that stretches only a length-one axis it is refused, and under label matching the result covers both label sets with absent values wherever they did not meet. Same expression, three answers.
saying these in an interview costs you the question
- Assumes a length mismatch always raises an error
- Says the shorter operand is always repeated until it fits
- Believes the tool infers the sensible pairing from the data itself
- Treats a warning line in the output as harmless noise
- Cannot say what comes back when a rule declines to stretch