Skip to content

Assert cliff precision on Nauvis: exact counts clear the shared code, localising #18 - #21

Merged
wormeyman merged 1 commit into
mainfrom
fix/nauvis-cliff-precision-guard
Jul 28, 2026
Merged

Assert cliff precision on Nauvis: exact counts clear the shared code, localising #18#21
wormeyman merged 1 commit into
mainfrom
fix/nauvis-cliff-precision-guard

Conversation

@wormeyman

Copy link
Copy Markdown
Owner

Follow-up to #20. Answers whether the cliff port is broadly bad or Vulcanus is specifically broken.

game ours recall precision over-placement
Nauvis seed 123456 282 282 0.943 0.943 1.000
Nauvis seed 777771 52 52 0.942 0.942 1.000
Vulcanus (3 regions) - - 0.57-0.69 0.38-0.57 1.14-1.58x

Nauvis places exactly the game's cliff count at both seeds. crossesCliff, the 4-tile lattice, the orientation table and the cell enumeration - everything the two planets share - demonstrably produce the right number of cliffs. #18 is therefore localised to what Vulcanus feeds them: makeVulcanusCliffFields, or the band constants ELEVATION_0 = 70 / INTERVAL = 120.

The shape of the error agrees: over-placing while also missing a third of the real cliffs means cells land in the wrong places, not merely too freely. A uniformly over-permissive gate would keep recall high and only depress precision. A wrong interval or offset shifts which elevation crossings exist, adding and removing cells at once.

Changes

  • Nauvis spec now asserts precision and an over-placement ratio alongside recall, so this failure mode cannot hide behind a recall number on either planet. The ratio bound is tight (< 1.1) deliberately - placement is deterministic and the measurement is exactly 1.000.
  • Corrects the spec's own stale figure: it claimed "~89-90%" from the original spike, and measures 94.3%. The port improved and nobody re-measured.
  • Verified neither planet's dump has duplicate positions, so set and array counting agree.

No behaviour change - src/ is untouched. pnpm run verify: 1140 pass, 0 fail.

🤖 Generated with Claude Code

https://claude.ai/code/session_018MiZeyBwzc9L1Hu6xiKvVe

… localising #18

Answers the question the Vulcanus capture raised: is the cliff port broadly
bad, with Nauvis's ~90% recall flattering it, or is Vulcanus specifically
broken?

| | game | ours | recall | precision | over-placement |
| --- | --- | --- | --- | --- | --- |
| Nauvis seed 123456 | 282 | 282 | 0.943 | 0.943 | 1.000 |
| Nauvis seed 777771 | 52 | 52 | 0.942 | 0.942 | 1.000 |
| Vulcanus (3 regions) | - | - | 0.57-0.69 | 0.38-0.57 | 1.14-1.58x |

**Nauvis places exactly the game's count at both seeds.** So `crossesCliff`,
the 4-tile lattice, the orientation table and the cell enumeration - all of
it shared between the planets - demonstrably produce the right number of
cliffs. #18 is localised to what Vulcanus feeds them: `makeVulcanusCliffFields`
or the band constants (ELEVATION_0 = 70, INTERVAL = 120).

The shape of the error agrees. Over-placing while also missing a third of
the real cliffs means cells land in the wrong places, not merely too freely;
a uniformly over-permissive gate would keep recall high and only depress
precision. A wrong interval or offset shifts which elevation crossings exist,
which adds and removes cells at once.

Adds precision and an over-placement ratio to the Nauvis spec so this class
of failure cannot hide behind a recall figure on either planet again. The
ratio bound is tight (< 1.1) on purpose: cliff placement is deterministic and
the measurement is exactly 1.000.

Also corrects the spec's own stale number - it claimed "~89-90%" from the
original spike and measures 94.3%. The port improved and nobody re-measured.
Verified no duplicate positions in either planet's dump, so set and array
counting agree.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018MiZeyBwzc9L1Hu6xiKvVe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant