Which row selections can be handed back as a window on the original's storage, and which must allocate?
answer
- describable, or collected
- start, count, step
- irregular positions cannot be described
- the shape permits, the design decides
basics
~20 sOnly a selection describable as a start, a count and a step can be expressed as a window, because those three numbers are the whole description. Positions with no regular pattern, and selections driven by a condition column, must gather their values into fresh storage.
solid answer
~50 sThe predicate is the **shape of the selection**, not the verb you wrote. If the wanted values sit at a regular spacing - every row from here to there, every second row, a contiguous run - the result can be described by where to start, how many, and how far apart, so it can be handed back as a window on the original's bytes with nothing allocated. If the positions form no regular pattern - an arbitrary list of positions, or the rows a full-length condition column picked out - there is no short description of where they sit, so the values have to be collected into freshly allocated storage. One caveat matters as much as the rule: a regular stride makes a window **possible**, not certain. Some designs duplicate eagerly anyway, and others defer the duplicate until something is written.
go deeper
Learn the two shapes by example: a contiguous run of rows has a short description, while a scattered list of positions does not and has to be collected.
Explain why the description matters - three numbers plus a reference are the whole result, so nothing is allocated - and give the gather case where no such description exists.
Add the part that costs people time in production: the shape only makes sharing possible, and the same expression can behave differently between tools, so the outcome is established rather than assumed.
Decide what the team is allowed to depend on. A rule that no routine may rely on the shape of a selection to control memory removes a whole class of surprises when the tool underneath changes.
## The predicate is the shape, not the verb People tend to look for the answer in the syntax - which surface was used, whether it was addressing by label or addressing by offset, whether the expression looked like a range or like a list. None of that is the predicate. The predicate is whether the set of values you asked for can be **described** rather than **collected**. A selection has a short description exactly when the wanted values sit at a regular spacing. Then three numbers say everything: **where to start, how many, and how far apart**. Rows 100 through 200, every second row, the whole of one column - each of those is a start, a count and a step. A result carrying only those three numbers and a reference to the original's storage is a **window onto the same bytes**: no bytes were allocated for the values, and producing it costs the same whether it covers ten rows or ten million. Now take a selection that has no such description: - **Gathering by an arbitrary list of positions** - rows 3, 17, 18 and 4,002, picked out in an order and with gaps that follow no pattern. - **A condition column** - a full-length column of outcomes, one per row, addressed back against the rows it was computed from. Which rows survive is data-dependent and irregular by nature. - Anything that changes the order of the rows, or repeats a row. For these there is nothing short to carry. The only way to hand back the result is to allocate storage for the surviving values and collect them into it, at a cost proportional to the number of rows kept. That is why the honest sentence is *a gather must allocate; a stride may not have to*. ## Why the two shapes differ so sharply | | regular stride | gather | |---|---|---| | description of the selected values | start, count, step | the positions themselves | | can be expressed without allocating | yes | no | | cost to produce | roughly constant | proportional to rows kept | | effect on the source's lifetime | may pin it | leaves it releasable | | examples | a contiguous run, every nth row, a whole column | a list of positions, the rows a condition kept, a reordering | ## The caveat that carries as much weight as the rule Being describable as a stride makes a window **possible**. It does not make it certain, and this is where two common one-line claims both fail: - *Selecting rows always copies, so a selection never shares the original's memory* - true of any gather, false of a stride in the designs that hand strides back as windows. - *A contiguous run is always a window* - false wherever the design chose to duplicate eagerly. What varies is the design's policy, and there are at least three live ones in this family: 1. **Eager duplication** - the result is materialised into freshly allocated storage whatever the shape, so the caller never has to reason about sharing and always pays for the bytes. 2. **Immutable by default, sharing untouched buffers** - the step returns a new handle that shares every buffer it did not need to change, so what is shared is decided per buffer rather than per selection. 3. **Deferring the duplicate until something is written** - the result is a logical duplicate immediately and bytes are allocated only when one side is modified, which makes the cost real but late. So the same expression, character for character, can be a window in one tool, freshly allocated storage in another, and a promised duplicate in a third. ## What this means when you are reading code 1. Establish the shape first: is this run of rows describable as a start, a count and a step, or are the positions irregular? 2. If it is irregular, you can stop - the values were gathered and the result owns them. 3. If it is regular, the shape permits sharing and you now have a question about the design rather than about the code, which is the point at which assuming is the error. ## How to answer this in an interview State the predicate in one sentence - *can the selection be described as a start, a count and a step* - give one example on each side, and then add the caveat unprompted. Candidates who stop at *strides are windows and gathers are copies* have the right mechanism and an overconfident quantifier; candidates who say *it always copies* have not looked. The strong answer is the shape rule plus the honest statement that the shape only makes a window possible.
- Why can a selection driven by a condition column never be a window?Because which rows survive is decided per row by the data, so the surviving positions have no regular spacing and no short description. There is nothing to carry except the positions themselves, so the values are collected into freshly allocated storage proportional to the number of rows kept.
- If a stride can be a window, why would a design hand back storage of its own anyway?To make behaviour predictable. If every result owns its bytes, a caller never has to reason about whether a result shares with its source or about what keeps a large buffer alive. The price is an allocation on every step, which designs that share untouched buffers or defer the duplicate avoid.
- Does selecting a single whole column count as a stride?By shape, yes: one column is a start, a count and a step, so it can be described rather than collected. Whether you are handed a window still depends on the design, and on how the table's storage is arranged underneath, which is a separate question from the shape of the selection.
saying these in an interview costs you the question
- Says selecting rows always allocates fresh storage
- Says a contiguous run is always a window
- Looks at the verb rather than the shape of the selection
- Thinks a condition column can be handed back as a window
- Treats the stride rule as a guarantee rather than a precondition