An element-wise sum of two columns: what lines the operands up when they carry row labels, and when they do not?

## Two operands, two ways to be lined up An element-wise operator has to answer one question before it can compute anything: **which value pairs with which**. There are exactly two answers in use in this family, and the operator does not choose between them - the operands do. - **By position.** A **plain numeric rectangle** - a packed typed buffer, meaning values of one representation stored end to end and addressed only by their offset - carries no row labels at all. There is nothing to match on except the offset. Value at offset 0 pairs with value at offset 0, and so on to the end. Because that is the only available matching, the lengths must agree for the pairing to be defined. - **By row label.** **A labelled column** carries its row labels alongside the data, precisely so that it can be lined up with another column by those labels rather than by where the values happen to sit. An element-wise operator over two such operands takes the union of the two label sets, pairs the values that share a label, and yields absence at any label that appeared on only one side. ## Why the same written expression gives two answers | | Two bare packed buffers | Two label-carrying columns | |---|---|---| | What the pairing is based on | the offset | the row label | | Effect of reordering one operand | every pair changes | nothing changes | | Labels present on only one side | no such concept | appear in the result, as absence | | Stored order of the result | the operands' shared order | determined by the combined labels | | Lengths that do not agree | not a defined pairing | not required to agree | This is the single most common way a correct answer becomes wrong the moment the interviewer changes the tool. A candidate who has only ever worked with label-carrying columns will say "it aligns on the labels" as though that were a property of element-wise arithmetic. A candidate who has only ever worked with packed buffers will say "it zips them" with the same confidence. Both are describing one design as though it were the class. ## The two failure modes this produces in real code 1. **Positional matching where you assumed labels.** Two buffers pulled from two sources that happen to be the same length but sorted differently will pair silently and wrongly. Nothing raises; the numbers are simply from the wrong rows. This is the quieter and more dangerous of the two, because the only symptom is that the answers are wrong. 2. **Label matching where you assumed position.** You add two label-carrying columns of a thousand values each, and get back **more** than a thousand results - because the two label sets only partly overlap and the union is larger than either. The extra positions are absent. The row count of the result is the cheapest signal that this happened, and it is worth looking at every time. ## Mixed operands When one operand carries labels and the other is a bare buffer of the same length, the usual behaviour is that the bare operand is consumed in its stored order against the labelled one's order, and the result keeps the labelled operand's labels. That is the sensible reading - a buffer has nothing to contribute to a label match - but it is a case worth confirming in whatever tool you are on rather than assuming, because the result has labels that one operand never agreed to. ## What a strong answer sounds like Say which operands carry labels *before* saying what happens. "If both carry row labels, the operator lines them up on the union of those labels and fills absence where they do not meet. If either is a bare positional buffer, the two are matched offset by offset and the stored order decides everything." That sentence is answerable by a candidate from any of these ecosystems, and it is the shape of answer an interviewer is listening for. Following it with the diagnostic - "so the first thing I check after an element-wise combine is whether the result is the length I expected" - is what moves it from recall to practice. ## The check that catches both failures - Compare the length of the result against the length of the operands. Larger means labels were matched and did not fully overlap. - Count how many absent values the result holds. A run of them concentrated at one end usually means two label sets that barely met. - If the operands came from different sources, do not trust a shared length as evidence of a shared order. Two thousand-row extracts sorted differently are the classic setup for a silent positional mismatch.