A whole-number column gains a few unrecorded values — when does it keep its integer form, and when is it re-stored wider?
answer
- every integer pattern already means something
- nothing spare to mean absent
- floating-point has a pattern set aside
- a validity track keeps the width
- exactness lost above a magnitude
basics
~20 sWhere the only absence marker is a pattern reserved inside the value, a whole-number encoding has no spare pattern, so the column is re-stored in a wider floating-point form. Where absence is tracked beside the values, the width is unchanged.
solid answer
~40 sIt depends entirely on how the tool encodes absence. In a fixed-width whole-number encoding **every** bit pattern already denotes a distinct integer, so there is nothing left over to mean "no value". A design whose only marker is a pattern reserved inside the value therefore has to move the column into a format that does have a spare pattern — the floating-point format, whose not-a-number pattern is the usual donor. That form is wider, and above a certain magnitude it can no longer represent every whole number exactly. A design that keeps a validity bit beside the values, or a typed absence marker stored outside them, changes nothing about the values: the column keeps its integer width and stays exact. So the widening is one design's consequence, not a law of tables.
go deeper
Recall that a column has one representation for all its values, and that adding a hole can force that representation to change. Knowing it can happen is enough before you can explain why.
Explain the mechanism: an integer encoding assigns every bit pattern to a number, so a marker living inside the value has nowhere to go, while a marker kept beside the values leaves the width alone.
Demonstrate the downstream judgment — identifiers and exact counts should not be allowed to drift into a form that rounds them, and the column's representation belongs in the checks rather than in your memory of what it used to be.
The angle is where the team pays: forcing a narrow, exact representation everywhere buys correctness on keys and counts but constrains which tools can hold the data, and that trade is a standing decision, not a per-script one.
## Why an integer encoding has nowhere to put a hole A column's declared representation is the one physical form every value in it is stored as, fixed for the whole column. For a fixed-width whole-number encoding, that form is exhaustive: **every** bit pattern in the width denotes some integer. There is no pattern left over that the format itself declares to be "not a value". That is the entire mechanism behind this question. The floating-point format is different by design. It sets aside part of its encoding space for things that are not ordinary finite numbers — infinities and a not-a-number pattern for results arithmetic cannot define. That spare pattern is what a tool borrows when it decides to encode absence *inside* the value. So the two facts collide: - a whole-number column has no pattern to lend; - a marker that must live inside the value needs one. The only way out, for a design with that single marker, is to store the column in a different format. That is the re-store, and it is a change to every value in the column, not just the absent ones. ## What the other designs do instead | absence encoding | does a whole-number column keep its form? | why | |---|---|---| | a pattern reserved inside the value | no | the integer encoding has no spare pattern, so the values move to a format that has one | | a validity bit beside the values | yes | the integers stay in their own buffer; presence is recorded in a parallel one-bit-per-row track | | a typed marker the tool defines | yes | the marker is the library's own value, stored outside the value's bits, so the buffer's form is untouched | | the host language's empty reference | the question does not arise | the cells are already references to arbitrary objects, so there is no fixed numeric width to preserve | This is the claim most worth stating carefully, because it is one of the sentences people repeat as though it were universal. **"An absent value forces a whole-number column wider" is true of designs whose only marker lives inside the value and false of the others.** A candidate who states it flatly is describing the tool they learned on; a candidate who states the mechanism and then says which designs it applies to is describing the class. ## What the re-store actually changes When the values do move into a floating-point form, three things follow, in rough order of how often they bite: 1. **Exactness above a magnitude.** A floating-point form spends part of its width on an exponent, so beyond some magnitude it cannot represent every whole number — only every second one, then every fourth, and so on. Two identifiers that differed in the source can land on the same stored number, and counts stop being exact totals. 2. **The column stops announcing that these are whole numbers.** Anything reading the declared representation downstream — an export, a check, another tool — now sees a decimal column and may format, round or compare it accordingly. 3. **The values themselves are all rewritten**, not just the absent cells. The column's present values are as affected as its holes. What the re-store does *not* change is the meaning of the holes: they are still unrecorded observations. And note what stays out of scope here — the byte-level accounting of what the column occupies afterwards is a different question, and so is the diagnosis of which operation triggered a change of representation in the first place. The point of this one is narrower: which absence encodings a whole-number column can host at all. ## Why a design cannot just reserve an integer for the job An obvious-looking alternative is to pick some integer — the smallest or largest representable one, say — and declare it to mean "absent". Designs do occasionally do this, and it has a hard cost: that integer is a legal value of the column's own type, so every operation reading the column sees an ordinary number there unless it has been specially taught otherwise. The value's meaning now depends on a convention that lives outside the data, and a legal input can no longer be stored. That is why the mainstream answers are the two that keep the marker *out* of the value space: a validity track beside the values, or a marker the tool owns. ## What to check on a tool you do not know - Put one hole into a narrow whole-number column and read back the column's declared representation. - Ask whether the tool offers a whole-number column that admits absence — a whole-number column keeping its integer width because presence is tracked beside the values. If it does, the widening is avoidable and it is your choice whether to pay it. - If you are carrying identifiers or exact counts, treat the representation as part of the contract of the column and assert it, rather than discovering the rounding downstream in a match that quietly fails.
- Why does a floating-point format have a pattern to spare when a whole-number one does not?A fixed-width integer encoding maps every bit pattern to a distinct integer, so the mapping is exhaustive by construction. A floating-point format splits its width into sign, exponent and fraction, and sets aside an exponent range for values that are not ordinary finite numbers — infinities and the not-a-number pattern. Those patterns collide with no real number, so a tool can borrow one without ambiguity.
- What is genuinely lost when a count column is re-stored in a floating-point form?Exactness above a magnitude. Beyond a point the form cannot represent every whole number, so large identifiers and large totals are rounded to a representable neighbour — two distinct source values can land on one stored value, and a match on that column then joins or misses rows for reasons invisible in the data. The declared representation also no longer says "these are whole numbers".
- How does a design admit absence in a whole-number column without widening it?It leaves the integers in their own buffer at their own width and records presence elsewhere: a parallel track of one bit per row, or a typed absence marker the library defines and stores outside the value's bits. Arithmetic still runs over integers, values stay exact, and the presence information is carried alongside rather than encoded inside.
saying these in an interview costs you the question
- Says a hole always turns a whole-number column into decimals
- Treats the widening as a rule of tables, not one design's consequence
- Assumes the re-stored column still holds every whole number exactly
- Thinks a validity track changes the width of the values themselves
- Believes reserving a real integer as the marker costs nothing