In a three-axis holding, why must code that reduces over the last dimension change its axis number after an earlier reduction?

## A dimension with no name In a positional multi-axis holding, a dimension has no identity of its own. It is identified entirely by where it sits in the **axis-length tuple** — the list of how long each axis is, whose number of entries is the number of axes. A holding of accounts by months by measures might have axis lengths (40,000, 60, 20). The account dimension *is* the first entry, the month dimension *is* the second, the measure dimension *is* the third. Nothing else names them. That is a perfectly workable model, and it is what lets the holding compute a cell's position arithmetically instead of looking anything up. But it has one consequence that surprises people every time: **the identifier is a position, and positions move.** ## What a reduction does to the tuple Averaging across the months collapses that dimension to a single number per remaining combination, so the month dimension is gone. The axis-length tuple goes from three entries to two: (40,000, 20). The remaining lengths close the gap. The measure dimension has not changed in any way a human would notice — it still has twenty positions and the same twenty meanings — but it is no longer the third entry. It is the second. Every later operation that identified it by position was written against the tuple as it was before the reduction, and that tuple no longer exists. ## The two failure modes - **Out of range.** The holding now has two dimensions, and a call naming the third is rejected. This is the good outcome: it is loud, it happens immediately, and it points at the line that is wrong. - **Silently the wrong dimension.** Start with four axes rather than three, remove one in the middle, and a call naming the fourth position now addresses what used to be the third. It is a legal dimension, of a legal length, and the operation succeeds. The result is wrong and nothing says so. The second is the reason this is asked at all. A number that is correct only given the order in which previous steps happened is a coupling between two pieces of code that nothing checks. ## Three ways out 1. **Keep the reduced dimension at length one.** Several designs offer a form of the reduction that writes a single value into the dimension instead of removing it. The tuple keeps the same number of entries, every later position keeps its meaning, and the holding is only marginally larger. This is the cheapest fix when the pipeline is already written against positions. 2. **Recompute the position instead of hard-coding it.** Read the current axis lengths and derive the position you want at the point you need it, so the value tracks whatever the previous steps did. 3. **Use a holding whose axes carry names.** In a **labelled multi-axis holding** — one with three or more axes where each axis carries a name and coordinate values as well as positions — the operation names the measure axis, and removing the month axis renames nothing. The problem does not arise, because no position was ever the identifier. ## The same selector, three different meanings The argument that tells an operation which way to run — **the axis selector** — is the same argument in all three of these holdings, and it names a different kind of thing in each. This is the single commonest confusion in this whole family, and it is worth being explicit about which one you mean before any number appears. | holding | what the selector names | does a reduction renumber anything? | |---|---|---| | two-axis table | the direction the operation runs: down the rows or across the columns | no — there are only two directions, and both always exist | | positional multi-axis holding | a dimension, by its place in the axis-length tuple | yes — removing one shifts every dimension after it | | labelled multi-axis holding | an axis, by its name | no — names do not move | The row that catches people is the first one. In a two-axis table the selector is not identifying a dimension at all; it is choosing between two directions, and which number corresponds to which direction routinely reads as the opposite of what people expect. Importing the positional reading into a two-axis table, or the other way round, produces code that runs and answers the wrong question. One more variation worth knowing: **which number the first dimension carries is not the same across designs.** Some count from zero and some from one. What does not vary is the mechanic underneath — removing a dimension shifts every dimension after it by one place — so reason about the shift rather than about the literal number. ## How to answer it Say that the identifier is a position rather than a name, that a reduction shortens the axis-length tuple, and that everything after the removed dimension therefore moves. Then name the failure that actually costs money — the call that lands on a legal but wrong dimension and produces no error — and give the fix you would actually use: keep the dimension at length one, or work in a holding where the axis has a name.