uber / h3-go / 39287006212

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, one key per function
holding a sequence for k 1 to 3 of 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.2 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... (continued)

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

4551 of 4551 relevant lines covered (100.0%)

4167257.4 hits per line