Why hand-build a debt-to-income ratio when the model already has both raw columns?

## What the model can and cannot reach Every model has a family of functions it can express. A linear model in two columns `d` (debt) and `i` (income) can produce anything of the form `w0 + w1*d + w2*i`. Geometrically that is a plane over the (d, i) space, and its contours — the sets of points that get the same prediction — are parallel straight lines. The function `d / i` is not in that family. Its contours are straight lines through the *origin*, fanning out at different angles: every point with debt equal to a third of income gets the same value, whether that is 10,000 on 30,000 or 200,000 on 600,000. No plane has fanning contours. So the honest statement is not "the model would find it slowly" — it is **cannot, at any sample size, with any coefficients**. That is the whole case for hand-built ratios. A ratio is a *normalisation*: it says the meaningful quantity is one column relative to another, not either alone. ## Why trees do not rescue you A tree can, in principle, approximate any function, so the argument is quantitative rather than absolute. A tree splits on one column at a time, `d < t` or `i < t`, so its decision regions are axis-aligned rectangles. The boundary `d = 0.4 * i` is a diagonal line, and a rectangle-based partition can only approximate a diagonal with a staircase. Each step of that staircase costs a split, and each split needs enough rows beneath it to be estimated reliably. With the ratio supplied as a column, the same boundary is a single split at `ratio < 0.4`. That is the difference between spending depth and data on rediscovering arithmetic and spending it on the parts of the problem that are genuinely hard. ## Ratios versus differences — not the same argument It is worth being precise here, because interviewers probe it. A **difference** such as `ship_date - order_date` *is* a linear combination: coefficients of +1 and -1 on the two columns produce it exactly. So a linear model can already represent fulfilment days from the two raw dates. The reasons to build the column anyway are different in kind: - **Trees cannot form it.** Axis-aligned splits on two date columns cannot express "the gap exceeded five days" any more than they can express a ratio. - **Regularisation and limited data.** A penalised linear model shrinks coefficients toward zero; the exact +1/-1 pairing that encodes a difference is one point in a large space, and with few rows the fit may never land near it. - **The raw columns carry a trend that the difference does not.** Order date drifts forward forever; fulfilment days do not. The derived column is the stable, extrapolable one. A useful bridge between the two cases: on the log scale a ratio *becomes* a difference, since `log(d) - log(i)` equals `log(d / i)`. So if both columns are already log-transformed, a linear model can reach the log-ratio on its own. ## Doing it safely **Guard the denominator.** Near-zero income, or a property listing with an area of 0.5 square metres, produces a value orders of magnitude above the rest of the column. Under squared-error loss, one such row can pull the fit visibly. Choose a rule and apply it identically at training and at scoring time: floor the denominator, add a small constant, clip the ratio at a training-set percentile, or emit a separate indicator column for the degenerate rows and let the model handle them apart. Zero denominators must never reach the model as infinities. **Decide whether to keep the parents.** The ratio deliberately discards absolute scale. Price per square metre says nothing about whether a listing is a 30-square-metre studio or a 300-square-metre house, and those are different markets. Keeping price, area *and* the ratio gives the model both views. For a tree ensemble this costs little beyond spreading importance across correlated columns. For a linear model, the ratio is correlated with its parents, which inflates coefficient variance and makes individual coefficients unstable — regularise, or validate which subset actually helps. **Keep it domain-driven.** Good ratios are the ones practitioners already reason with: debt-to-income, price per square metre, revenue per employee, cost per acquisition. They are predictive *and* explainable, which makes the model easier to defend. Generating every pairwise ratio in a wide table is the opposite: it multiplies columns without adding understanding, and most of the new columns can only fit noise. ## The interview summary Ratios encode a relationship no linear model can reach and no tree can reach cheaply. Build the handful the domain justifies, protect the denominator, keep the parents unless validation says otherwise, and be able to state precisely why a difference is a different case from a quotient.