res2display() order cap still wrong above order 20 — carry-forward from #88 — PR #76

[espg]

mortie/tools.py::res2display() still loops for res in range(20), so it silently returns nothing for any order above 19 even though the packed-u64 kernel supports order 29.

...it would be ideal if this had some checking added to format the floating point sensibly, especially when it drops below 1.0 ; i.e.,

1.5889124267578125 km at tessellation order 12  # this should truncate down to 1.589 km
0.7944562133789063 km at tessellation order 13 # this should return meters, i.e., 794.456 m

[espg]

🤖 from Claude

Plan: fix res2display() order cap + sensible unit formatting

Recommendation: extend the display loop to the full order range and add a small unit ladder (km → m → cm) so fine orders read naturally instead of as tiny km fractions. This is a plan issue, so no code below — phased steps, files, acceptance criteria, and open questions.

Where the gap is (grounded)

res2display at mortie/tools.py:22-25:

def res2display():
    '''prints resolution levels'''
    for res in range(20):
        print(str(order2res(res)) + ' km at tessellation order ' + str(res))

order2res(order) = 111 * 58.6323 * 0.5**order (tools.py:17-19) has no order cap — it's the loop bound range(20) (orders 0–19) that silently drops orders 20–29, even though the packed-u64 kernel supports order 29 (MAX_ORDER, src_rust/src/decimal_morton.rs:55). Two defects, then: (1) orders 20–29 never print; (2) sub-km orders print as ugly km fractions (order 18 shows 0.0248… km rather than 24.83 m).

Exact values from order2res (confirms the issue's examples):

order	km	m	cm
0	6508.185 km	—	—
12	1.589 km	1588.912 m	—
13	0.794 km	794.456 m	—
18	0.0248 km	24.827 m	—
19	0.0124 km	12.413 m	—
25	—	0.194 m	19.396 cm
29	—	0.0121 m	1.212 cm

So order 12 → 1.589 km and order 13 → 794.456 m exactly match the issue's requested output.

Phased implementation

• Phase 1 — extend range + unit ladder. Loop orders 0..=29 (range(MAX_ORDER + 1) = range(30), sourced from the kernel constant rather than a bare literal). Pick a unit by magnitude: >= 1 km → km; >= 1 m (i.e. < 1 km) → m (value × 1000); < 1 m → cm (value × 100000) — see Question (1) on whether to add the cm rung. Format the number to a fixed precision (3 decimals — see Question (3)) so lines read 1.589 km at tessellation order 12 / 794.456 m at tessellation order 13. Keep the trailing at tessellation order N phrasing so existing readers aren't surprised.
• Phase 2 — test. Add a capsys-based test in mortie/tests/test_tools.py (where the other tools tests live) asserting: all 30 orders are printed (0–29, closing the cap); order 12's line contains km; order 13's line contains m (and not km); the fine end (order 29) uses the expected unit; and the numeric render matches the rounded expected value for a couple of pinned orders. This pins both the cap fix and the formatting.

Files likely touched

• mortie/tools.py — res2display (22-25) only; order2res is already order-unbounded and needs no change.
• mortie/tests/test_tools.py — new stdout-capture test.

Acceptance criteria

• res2display() prints one line per order 0–29 (no silent drop above 19).
• Orders whose resolution is < 1 km render in m (and, if adopted, < 1 m in cm) rather than as km fractions; order 12 → 1.589 km, order 13 → 794.456 m.
• A test pins the order count and the km/m boundary; flake8 --select=E9,F63,F7,F82 clean and pytest -v green.

Questions for review (one pass)

1. Unit ladder depth. km + m only (order 29 then reads 0.012 m), or add a cm rung so the finest orders read naturally (order 25 → 19.396 cm, order 29 → 1.212 cm)? Recommend km/m/cm — the whole point is legibility at fine scales, and orders 25–29 are all sub-meter. (mm would only matter below order 29, which doesn't exist, so I'd stop at cm.)
2. Signature. Keep res2display() argument-less (print-only, backward compatible) and just extend it to 29, or add an optional max_order=29 (and/or a returned list) so callers can bound/consume it? Recommend keeping it argument-less by default to avoid changing the contract, optionally adding max_order=29.
3. Round vs. truncate + precision. The issue text says "truncate down to 1.589 km", but 1.588912… truncated is 1.588 while the requested 1.589 is rounded — and 794.4562 → 794.456 is likewise rounding. So the examples are consistent with round to 3 decimals, not truncation. Confirm round-to-3-decimals is what you want (that's what I'd implement)?

Marking waiting on your read of (1)–(3). No code/branch from me on this plan issue.

---

Generated by Claude Code

[espg]

Unit ladder depth. km + m only (order 29 then reads 0.012 m), or add a cm rung so the finest orders read naturally (order 25 → 19.396 cm, order 29 → 1.212 cm)? Recommend km/m/cm — the whole point is legibility at fine scales, and orders 25–29 are all sub-meter. (mm would only matter below order 29, which doesn't exist, so I'd stop at cm.)

yes, km/m/cm makes sense

Signature ... Recommend keeping it argument-less by default to avoid changing the contract, optionally adding max_order=29.

yes, agree -- at the optional max_order=29

Round vs. truncate + precision. The issue text says "truncate down to 1.589 km", but 1.588912… truncated is 1.588 while the requested 1.589 is rounded — and 794.4562 → 794.456 is likewise rounding. So the examples are consistent with round to 3 decimals, not truncation. Confirm round-to-3-decimals is what you want (that's what I'd implement)?

yes, round to three decimals within a km/m/cm bracket