Under leaf-wise growth, why is a cap of 63 leaves not equivalent to a depth cap of 6?

## The arithmetic that makes them look interchangeable A binary tree of depth `d` has at most `2^d` leaves, so a depth cap of 6 admits at most 64 leaves, and a cap of 63 leaves sounds like the same budget from the other end. It is the same budget only in the balanced case. The two caps are one-directional: depth bounds leaves (`leaves <= 2^depth`), but leaves bound depth only trivially (`depth <= leaves - 1`). Sixty-three leaves permits any shape between a balanced depth-6 tree and a 62-deep chain. ## Why the gap is real under leaf-wise growth Level-wise growth never explores the lopsided end of that range: it splits a whole frontier at a time, so a tree with 63 leaves is necessarily close to depth 6. Best-first growth has no such tendency — it puts the next split wherever the gain is largest, and gains are usually largest in whichever region already contains structure. Deep, one-sided branches are the *typical* output, not the pathological one. On an 800-row employee-attrition pilot extract this is easy to observe: with only a leaf cap in force, best-first growth runs to depth 20 along a single branch while level-wise growth on the same data stops at depth 6. ## What each cap actually buys **A leaf-count cap buys capacity control.** The number of terminal regions is the honest measure of how many distinct predictions one tree can make, so this is the dial that trades bias for variance most directly. Halve the leaf cap and you roughly halve the tree's expressiveness regardless of its shape. **A depth cap buys interaction-order control and support.** A path of `k` splits can involve at most `k` features, so depth is a ceiling on how many features may jointly define a region — which matters both for generalisation and for anyone who has to read the model. Depth also correlates with row support: each split divides the rows reaching it, so leaves at depth 20 on 800 rows sit on a handful of examples each, whatever the leaf cap says. ## The trap of setting only one Set only the leaf cap and you get the deep, low-support branches above. Set only the depth cap under leaf-wise growth and something subtler happens: because expansion is gain-ordered, the tree may stop far short of `2^depth` leaves — gain thresholds and minimum-support rules bite first — so the depth cap is not really controlling capacity, and two runs with the same cap can produce very differently sized trees. Worse, if the depth cap is the binding constraint, the leaf cap you tuned has no effect at all, and a later change to it looks inert. ## A workable configuration discipline 1. Choose the leaf-count cap as the primary capacity dial and tune it. 2. Set a depth cap as a *guardrail* that is loose relative to the leaf cap — loose enough that it rarely binds on large data, tight enough to forbid the 40-deep branch on small data. 3. Add a floor on the number of rows (or the summed hessian) required to form a leaf, which is what actually protects the tail branches; on a few hundred rows this floor does more work than either cap. 4. Verify which constraint bound by inspecting the trees you got — actual leaf counts and actual depths — rather than assuming your settings were the active ones. ## Small and noisy data The smaller the dataset, the more the caps matter and the more the depth guardrail earns its place, because the gain estimates driving best-first expansion are themselves noisy. A defensible default on a few hundred rows is a small leaf budget, a shallow depth guardrail and a meaningful minimum leaf support — or level-wise growth, whose balanced shape is a crude but effective form of the same restraint. ## What an interviewer is checking Whether you understand that these caps are not two spellings of one setting. The candidate who says "63 leaves is depth 6" has assumed balance, which is exactly the assumption leaf-wise growth abandons.