fix(adr-025): correct the LOD depth formula — n = 16^r (4×4), not 4-ary#45
Conversation
Closes Codex P2 on PR #44 (now merged). # The error ADR-025 §2 said sample size "n ≈ 16^r for a 4-ary radix pyramid." That is internally inconsistent: a 4-ary pyramid grows as n = 4^r, and the cited level formula r* = ⌈log₄(C/τ)⌉ only follows from n = 16^r. As written, an implementer of D-JC-PREDICT-LOD building against the documented 4-ary pyramid would pick a level half as deep as needed and leave the predicted error above tolerance. The runtime session's original numbers were actually self-consistent on n = 16^r (it gave n^{-1/2} = 4^{-r} and r* = ⌈log₄(C/τ)⌉, which all agree). The only slip was my mislabeling the branching as "4-ary" — the pyramid increases resolution ×4 in BOTH x and y per hop, so 4 × 4 = 16 samples per level. # The fix Rewrite §2 with an explicit, self-checking derivation: n = b^r predicted_error_L = C · n^{-1/2} = C · b^{-r/2} predicted_error_L < τ ⟹ r* = ⌈2·log_b(C/τ)⌉ (general) helix pyramid ships b = 16 (×4 per axis = 4 × 4) ⟹ n = 16^r, n^{-1/2} = 4^{-r} ⟹ r* = ⌈2·log_16(C/τ)⌉ = ⌈log₄(C/τ)⌉ (canonical anchor) The canonical formula r* = ⌈log₄(C/τ)⌉ and the "5-12 hop" range are preserved (the §Consequences line now annotates it as the b = 16 reduction of r* = ⌈2·log_b(C/τ)⌉). The "4-ary radix pyramid" label is removed. # Implementer note added The §2 block now carries an explicit warning: build the level formula on the pyramid's true per-level SAMPLE growth (n = 16^r), not its per-axis fan-out (×4). Pairing the ⌈log₄⌉ pick with a pyramid that actually grows only n = 4^r selects a level half as deep as that pyramid needs (a 4-ary pyramid needs ⌈log₂(C/τ)⌉, since log₂ = 2·log₄) and leaves the error above tolerance — exactly the failure mode Codex flagged. # Review Numerically re-derived and verified: - 2·log_16(C/τ) == ⌈log₄(C/τ)⌉ across C/τ ∈ {1024, 4096, 1e5, 1.67e7} - n^{-1/2} == 4^{-r} at b = 16 - footgun direction: applying ⌈log₄⌉ to a 4-ary pyramid picks exactly half the needed depth (ratio 0.50 vs ⌈log₂⌉) — matches Codex's "half as deep as needed" - 5-12 hop band (b=16): r*=5 ⇔ C/τ~1024, r*=12 ⇔ C/τ~1.68e7 No "4-ary" mislabel remains in the doc. PII abort-guard (word-boundary): CLEAN. cargo check --workspace --all-targets: clean (docs-only). https://claude.ai/code/session_01PBTGaPCSnnt6u3pjXpbLwY
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 110dd3bd9d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| (L^q regime, which the Σ-sandwich Mahalanobis distance lives in). | ||
| Solving `predicted_error_L < τ` for the smallest accepting level: | ||
| `C · b^{-r/2} < τ ⟹ b^{r/2} > C/τ ⟹ r > 2·log_b(C/τ)` | ||
| **`r* = ⌈2·log_b(C/τ)⌉`** for clinical tolerance τ — closed-form, |
There was a problem hiding this comment.
Handle equality when deriving the strict LOD threshold
When C/τ is exactly a power of b, this ceil formula returns a level whose predicted error is equal to the tolerance, not below it: e.g. if C/τ = b^k, then r = 2k gives C·b^{-r/2} = τ while the text requires predicted_error_L < τ. Since this ADR is explicitly the implementer guidance for D-JC-PREDICT-LOD, that boundary case would select one level too shallow unless the acceptance condition is changed to <= or the formula uses the smallest integer strictly greater than 2·log_b(C/τ).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in PR #46. You're right — strict < with ⌈⌉ is off-by-one at C/τ = b^k. Switched the acceptance to inclusive ≤ τ (also Cesium SSE's sse ≤ maxSSE convention), which makes r* = ⌈2·log_b(C/τ)⌉ exact: at the boundary r* = 2k gives predicted_error = τ, accepted by ≤. The strictly-below alternative r* = ⌊2·log_b(C/τ)⌋ + 1 is now documented for deployments that need it. Numerically re-verified.
Summary
Closes Codex P2 on PR #44 (now merged). Per the established pattern, fresh PR rebased on current
main(which includes the #44 merge).The error
ADR-025 §2 said sample size "n ≈ 16^r for a 4-ary radix pyramid." That's internally inconsistent: a 4-ary pyramid grows as
n = 4^r, and the cited formular* = ⌈log₄(C/τ)⌉only follows fromn = 16^r. As written, an implementer ofD-JC-PREDICT-LODbuilding against the documented 4-ary pyramid would pick a level half as deep as needed and leave the predicted error above tolerance.The runtime session's original numbers were actually self-consistent on
n = 16^r(it also gaven^{-1/2} = 4^{-r}andr* = ⌈log₄(C/τ)⌉, which all agree). My only slip was mislabeling the branching as "4-ary" — per the user's correction, the pyramid increases resolution ×4 in both x and y per hop, so4 × 4 = 16samples per level.The fix
Rewrote §2 with an explicit, self-checking derivation:
r* = ⌈log₄(C/τ)⌉and the "5-12 hop" range are preserved (the §Consequences line now annotates it as theb = 16reduction ofr* = ⌈2·log_b(C/τ)⌉).4-aryoccurrences remain).Implementer note added
§2 now carries an explicit warning matching Codex's flagged failure mode: build the level formula on the pyramid's true per-level sample growth (
n = 16^r), not its per-axis fan-out (×4). Pairing the⌈log₄⌉pick with a pyramid that actually grows onlyn = 4^rselects a level half as deep as that pyramid needs (a 4-ary pyramid needs⌈log₂(C/τ)⌉, sincelog₂ = 2·log₄) and leaves the error above tolerance.Review (numerically re-derived)
2·log_16(C/τ) == ⌈log₄(C/τ)⌉over C/τ ∈ {1024, 4096, 1e5, 1.67e7}n^{-1/2} == 4^{-r}at b = 16⌈log₄⌉on a 4-ary pyramid = exactly half the needed depth⌈log₂⌉(matches Codex "half as deep as needed")r*=5 ⇔ C/τ~1024,r*=12 ⇔ C/τ~1.68e7PII abort-guard (word-boundary): CLEAN.
cargo check --workspace --all-targets: clean (docs-only).https://claude.ai/code/session_01PBTGaPCSnnt6u3pjXpbLwY