Two columns with different representations are combined in one arithmetic expression. What decides the representation of the column that comes back?
answer
- one result, so one representation
- narrow resolves toward the more general
- no common form: refuse or hold anything
- resolution happens before the operation
basics
~20 sThe operation resolves both operands to one representation before it runs, and the result carries that. Across designs the resolution takes three shapes: widen to the more general common type, refuse, or fall back to a representation holding anything.
solid answer
~50 sA result is a column, and a column holds one representation, so mismatched operands have to be reconciled before the operation runs. Inside a single kind of value the reconciliation is a widening to the more general common type: two whole-number forms of different width give the wider, a whole-number column with a fractional one gives fractional, truth values used in arithmetic count as one and zero. Across kinds there may be no common typed form at all — a number and a piece of text have none — and there the designs in this family genuinely split. Some refuse the expression, the loud, cheap outcome. Some fall back to a representation that stores one reference per row and lets each row be a different kind of thing, which keeps running and quietly costs the single typed pass. Name all three, then say which one your design does.
go deeper
Recall that the result of an expression is one column with one representation, so two mismatched operands must be reconciled first. The narrow side usually moves toward the more general one.
Explain the resolution as a step that runs before the operation, walk the narrow-to-general ordering, and name all three dispositions rather than presenting widening as the only one there is.
Demonstrate that you know which disposition your own stack takes and how you established it, and that you can trace unexplained slowness back to a column that fell back to holding anything.
The call is whether to run on a stack that reconciles quietly or one that refuses. Refusal costs developer time on every mismatch and buys you that no wrong representation can reach a report.
## One result means one representation Two columns meet in one expression — added, subtracted, or compared **element-wise**, meaning one row of one column against the same row of the other, the whole column said once rather than a step per row. Their **column representations** — the single physical form every value in each column is stored in — are not the same. Whatever comes back is a column, and a column holds exactly one representation, so something has to decide which. That decision belongs to the operation, and it takes one of three shapes: 1. **Widen both operands to the more general common type** and run the operation once over two columns that now match. 2. **Refuse the expression** and make the author state which representation was meant. 3. **Fall back to a representation that can hold anything** — one reference per row, each row free to be a different kind of thing. Which of the three you get is a property of the design you are working in, not a universal rule. An answer that states one of them as *the* behaviour is wrong somewhere, and this is the single most useful thing to say out loud in an interview on this subject. ## Widening to the more general common type Inside one kind of value there is an ordering from narrow to general, and resolution walks up it until both operands fit: - two whole-number forms of different width resolve to the wider of the two; - a whole-number column and a fractional one resolve to fractional; - a column of truth values used in arithmetic resolves to a whole-number form, with the truth values standing in as one and zero; - two fractional forms of different precision resolve to the more precise. The important mechanical detail is that this happens **before** the operation, not after it. Both operands are brought to the common type, and then a single typed pass runs over matching columns. Three costs ride along, and a candidate who names them is ahead of one who only names the rule: - **A second buffer.** Changing a representation means writing new bytes, so the original buffer and the converted one are both live for the duration of the step. This is the honest worked example of a step that really does hold two copies at once: a re-labelling or a re-ordering may share the same bytes, a conversion cannot, because these bytes genuinely changed. - **Exactness.** Widening a long whole number into a fractional form is lossless only below a magnitude threshold. Above it, neighbouring whole numbers collapse onto one stored value, which is invisible until something compares them. - **Width per row.** The result occupies the wider form for every row, including the rows that would have fitted the narrow one. ## When there is no common typed form A number and a piece of text have no more-general shared numeric form, and this is where designs disagree most sharply. - **Refusal.** The expression stops at your line. It costs an hour and nothing downstream is affected. This is the loud half, and it is the cheapest outcome to live with even though it feels like the most obstructive. - **A fall back to the holder-for-anything representation.** Nothing is refused and no value is lost. The column now stores one reference per row, pointing at values allocated separately, and any operation over it has to establish each value's kind before it can act on it instead of running one pass over a packed buffer. It is silent at the moment it happens and turns up a week later as a step that used to take a second. | operand pair | most common outcome | what varies across designs | |---|---|---| | two whole-number forms of different width | the wider form | strict designs refuse rather than widen on their own | | whole-number and fractional | fractional | whether exactness loss at large magnitude is reported at all | | truth values and whole numbers | whole numbers, as one and zero | some designs refuse arithmetic on truth values outright | | number and text | refusal, or a holder-for-anything column | the pair where designs disagree most | | two columns of text held differently | one text form | which of the two storage forms the result uses | ## How to find out which regime you are in You do not have to read anything to answer this for your own tools. Build a two-row table, combine a narrow whole-number column with a fractional one, then with a column of text, and look at what each expression hands back: a wider typed column, an error at that line, or a column that is now a reference per row. Three small expressions settle which of the three dispositions you are living under, and the answer is stable enough to rely on afterwards. ## What to say in an interview Name the three dispositions, say that the one you get is a property of the design rather than a law, and then give the tell: after an expression whose operands did not match, the thing to look at is what the result is made of, not what it contains. Finish on the half-and-half point — refusal is loud and survivable, and the two outcomes that keep running are the ones that reach a report.
- What does widening cost, given that none of the values themselves change?Changing a representation means writing new bytes, so the source buffer and the converted one are both live while the step runs. Even designs that share untouched buffers between steps cannot share this one, because these bytes are genuinely different. On top of that, every row pays the wider form, and a long whole number widened into a fractional form stops being exact above a magnitude threshold.
- Why is a fall back to a representation that holds anything worse than a refusal?A refusal stops at the line that caused it, so you pay an hour and nothing downstream is wrong. A fall back keeps running with every value intact, which is why nobody notices, and replaces a single pass over a packed buffer with work that has to establish each value's kind first. The cost surfaces later as unexplained slowness, far from the expression that caused it.
- How would you establish whether your own tooling widens, refuses, or falls back?Write three tiny expressions over a two-row table: a narrow whole-number column against a fractional one, the same column against text, and a column of truth values used in arithmetic. Each hands back a wider typed column, an error, or a column of one reference per row. That is the whole experiment, and the result generalises across the rest of the pipeline.
saying these in an interview costs you the question
- Thinks the left operand's representation always wins.
- Believes each row can keep its own type inside a column.
- Says operands of different kinds are always refused.
- Misses that widening writes a second buffer and can lose exactness.
- Treats a fall back to holding anything as free because no value was lost.