An average over a column of whole-number counts comes back fractional. Why is the result's representation a property of the operation?
answer
- the operation decides, not the inputs
- an average is a division
- closed rules against widening rules
- accumulator width varies by design
basics
~20 sEvery operation has a result rule that fixes what its output column is made of; the inputs only feed it. An average is a division, defined over fractional values, so whole numbers in still gives fractional out.
solid answer
~50 sAsk what the operation is *defined* to return, not what went into it. An average divides a total by a count, and the exact quotient of two whole numbers usually is not a whole number, so the operation's result rule says fractional whatever the input column held. Division behaves the same way, and a comparison goes further still: it hands back a column of truth values, which is neither operand's form. A total is the interesting middle case, because designs disagree — some accumulate into a representation wider than the column so a long run of values cannot run off the end of the range, others accumulate in the column's own width. The honest habit is per-operation: name the operation, then state its result rule. A representation that moved is expected behaviour for a large share of operations, and the defect is not knowing which share you are in.
go deeper
Recall that an average and a division hand back fractional values even when every input was a whole number. The operation's own definition decides that, and it is normal behaviour rather than a fault to be repaired.
Explain the result rule operation by operation: which are closed over their input form, which widen by definition, and which return truth values. Say what varies about the width a total accumulates in.
Show that you check an operation's result rule before the expression ships, and that you know the quiet half — a usable column whose representation moved and whose largest values are now approximations nothing reported.
The standing tradeoff is how much of a pipeline's typing you let result rules decide on their own. Pinning representations at every boundary costs friction on each step; leaving it to the operations costs exactness nobody measures.
## The rule belongs to the operation, not to the inputs Every column carries one **column representation** — the single physical form every value in that column is stored in. When an operation hands back a new column, that new column has a representation of its own, and it is fixed by the operation's **result rule**. The inputs are arguments to that rule; the result does not inherit from them. That reframing is most of the answer. "My whole-number column became fractional" sounds like a fault, and it is not one. An average is a total divided by a count, the exact quotient of two whole numbers usually is not a whole number, and so the operation is defined to produce fractional values. Feed it whole numbers and you still get a fractional column, including for the rows that happen to land exactly on a whole number — a fractional value of four prints like a whole four and is not stored like one. ## Some result rules are closed, and some are not | operation | usual result rule | why | |---|---|---| | adding two columns of the same whole-number form | the same form | the sum of two whole numbers is a whole number | | division | fractional | the exact quotient rarely is a whole number | | an average | fractional | it is a division | | a total | the same form, or a deliberately wider one | designs disagree; see below | | a comparison | a column of truth values | neither operand's representation survives | | a count of rows | a whole number | counting cannot produce a fraction | | a proportion or a rate | fractional | it is a division | Read that as a habit rather than as a list to memorise: **name the operation, then state its result rule.** Someone who does that is never surprised, because the surprise only exists for a reader who expected the output to inherit from the input. ## Where designs genuinely differ This is not one rule across the tools in this space, and an answer that states one design as the class will be wrong somewhere: - **The accumulator for a total.** Some designs add a column up in a representation wider than the column's own, precisely so that a long run of ordinary values cannot exceed the input's range partway through. Others accumulate in the column's own width, which is faster and means a large total can pass the top of that range. The two are indistinguishable until the numbers get big. - **Whether a whole-number division exists separately.** Some designs offer two divisions — one returning the exact fractional quotient and one defined to discard the remainder and stay whole — so the result rule becomes something you choose. Others expose only the fractional one. - **Whether mixed-kind arithmetic resolves or refuses.** Some designs quietly bring two different input representations to a common one; others refuse the expression and make you say which you meant. - **What an average over an empty column returns.** Some hand back a marker meaning nothing was there, some refuse, some return zero. Those are three different answers to the same expression. So the honest formulation is comparative: *on designs that accumulate into a wider representation…, whereas on designs that accumulate in the column's own width…*. That is not hedging, it is the content, and it is the only form of the answer that survives moving between ecosystems. ## The loud half and the quiet half When a result's representation is not the input's, two things can follow. 1. **It is loud.** The operation refuses, or the next step refuses the column it was handed, and you fix it at the line that caused it. This half costs an hour and teaches you the rule. 2. **It keeps running.** The fractional column is perfectly usable. Arithmetic on it works, a chart of it draws, and a report built from it looks right. Nothing anywhere announces that the representation moved. The quiet half is what earns interview time, and the reason is exactness. A fractional representation keeps a fixed number of significant digits. Below a threshold every whole number in it is exact; above that threshold, neighbouring whole numbers collapse onto the same stored value. A column of long numeric identifiers that has been through a fractional result rule can hold values that no longer compare equal to the originals, and every one of them still looks like an ordinary number on screen. ## What to do with it - Before writing an expression, ask what it is defined to return. If the answer is fractional, decide whether that is acceptable here rather than discovering it three steps downstream. - When a step must stay whole, use the operation whose result rule is whole rather than converting the fractional result back afterwards: converting back re-rounds a value that has already been approximated once. - Know which half you are in. If the operation refused, you are finished. If it handed back a usable column, the only record that anything changed is the one you are keeping in your head. - In an interview, say the rule out loud: the operation decides, the inputs only feed it, and roughly half the operations you use every day are not closed over their input form.
- Which common operations return a column whose representation is neither operand's?A comparison returns a column of truth values regardless of what went in. A division or an average returns fractional values from whole-number inputs. A count of rows returns a whole number from inputs of any kind at all. In every case the result rule is a property of the operation, so naming the operation is enough to predict what comes back.
- Why is a fractional result a risk for long numeric identifiers even though nothing was raised?A fractional representation keeps a fixed number of significant digits. Below a threshold every whole number is held exactly; above it, neighbouring whole numbers collapse onto the same stored value. Identifiers are usually long, so equality tests and matches against the original values can start failing while every value on screen still reads as an ordinary number.
saying these in an interview costs you the question
- Assumes a result inherits the representation of its inputs.
- Says an average over whole numbers stays whole.
- Claims every design accumulates a total into a wider representation.
- Treats a fractional result as a bug rather than the defined rule.
- Believes a fractional representation holds every whole number exactly.