uber / h3-go / 39277190412

100%

master: 100%

Pull #169

github

conformance: record where the unsafe traversals refuse

gridDiskUnsafe and gridRingUnsafe walk the grid in a spiral and refuse
with E_PENTAGON when the walk meets a pentagon; the safe functions fall
back to a slower search and always succeed. Callers use the unsafe
functions for speed and handle the refusal themselves, so which origins
and k are refused is part of the contract. The rule is a property of the
reference's walk rather than of the geometry: the disk refuses when any
visited cell is a pentagon, and the ring refuses when a cell on the way
out or around the ring is a pentagon or when the circuit does not return
to its first cell. The suite recorded only the safe functions, which
succeed every time, so nothing in it could tell whether a port refuses in
the same places. paritytest covers this today by running both
implementations over its corpus, and it is going away with the cgo
binding.

Add an unsafe stream, unsafe/cells.jsonl, one line per valid cell with
the outcome of gridDiskUnsafe and gridRingUnsafe for k 1 to 3: true on
success, or the error. A success carries no cells because the reference
returns exactly the safe function's cells when the unsafe one succeeds,
so a runner checks its unsafe output against its own safe output, which
the traversal stream and the digests already vouch for. That keeps the
file at 1.6 MB where repeating the sets would have cost over 20 MB.
gridDiskDistancesUnsafe is the function gridDiskUnsafe calls and
gridDisksUnsafe is a loop over it, so neither gets a key.

The subjects are the valid-cell sample with n = 16 plus every cell within
four of every pentagon at every resolution, since random cells almost
never sit near a pentagon at high resolution and the decision changes
only there. That is 9,527 cells; about a third of the k = 3 disks and
rings are refused. In the generated file the disk and ring decisions
agree for every subject; both are recorded because they are separate
walks and a port can get one rig... (continued)

1 of 1 new or added line in 1 file covered. (100.0%)

4551 of 4551 relevant lines covered (100.0%)

4167350.74 hits per line