on_minor_arc FP/SoS hardening

[espg]

from #73

(1) on_minor_arc FP sensitivity in robust_crossing — PR #44 (hemisphere+ PIP)

The Phase-7 SoS hardening covers robust_crossing's four straddle gates but not its antipodal-disambiguation on_minor_arc, which still uses raw f64 signs. A probe point lying exactly on a polygon edge's great circle can flip on floating-point noise, silently producing incorrect PIP results with no error raised. PR #44 author explicitly recommended opening a follow-up issue for this. Not a known active bug, but a latent correctness risk on edge-great-circle inputs.

[espg]

🤖 from Claude

Plan: SoS-harden on_minor_arc in robust_crossing

Recommendation: mirror the existing orient_sos SoS treatment already applied to robust_crossing's four straddle gates onto the antipodal-disambiguation step, replacing the two raw f64-sign half-plane tests in on_minor_arc with an exact/SoS-consistent decision keyed to the same point identities the gates already carry. This is the residual sensitivity the code itself already flags as un-hardened.

Where the gap is (grounded)

robust_crossing (src_rust/src/sphere.rs:284-312) hardens its four straddle determinants through orient_sos (sphere.rs:295-301), which decides on a canonical, identity-sorted evaluation and breaks exact-zero ties with Simulation of Simplicity (sphere.rs:181-249). But the antipodal disambiguation that follows is not hardened — it calls on_minor_arc (sphere.rs:265-268):

fn on_minor_arc(x: &Vec3, a: &Vec3, b: &Vec3) -> bool {
    let ab = cross(a, b);
    dot(&cross(a, x), &ab) >= 0.0 && dot(&cross(x, b), &ab) > 0.0
}

Both comparisons are raw f64 signs with no identity tie-break and no ia/ib arguments. When the probe point x lies exactly on edge AB's great circle (the issue #11 family — a cell centre on a base-cell-centre meridian), cross(a, x)·ab and cross(x, b)·ab round near zero and can flip on float noise, silently choosing the wrong antipodal intersection. This is documented verbatim at src_rust/src/coverage.rs:438-442: "robust_crossing's on-arc disambiguation is not itself SoS-hardened, so an on-great-circle probe can still admit a residual float-sign sensitivity there." Today the descent only tolerates it because such cells are also caught by node_straddles and refined rather than filled (coverage.rs:442) — a containment, not a fix.

robust_crossing is reached on the degenerate path from edge_crosses_probe (coverage.rs:482), called with probe ids PROBE_ID_P=0, PROBE_ID_Q=1 and edge ids e.ia/e.ib (coverage.rs:351-355, 366-408) — so the identities on_minor_arc would need are already in hand at the one call site.

Phased implementation

• Phase 1 — characterize the failure. Add a failing/pinned test that drives robust_crossing (and, end-to-end, point_in_ring_robust) with a probe point placed exactly on a polygon edge's great circle, where the two on_minor_arc dot products land within float noise of zero. Demonstrate sign-flip sensitivity under vertex/argument reordering (the analogue of test_orient_sos_antisymmetric_brute_force at sphere.rs:604, and test_robust_pip_consistency_under_vertex_rotation at sphere.rs:1003). This pins the previously-flippable case before touching logic.

• Phase 2 — exact/SoS sign treatment. Replace the two raw comparisons with a decision that reuses the canonical-order + SoS machinery the four gates use. Concretely: give on_minor_arc the point identities (x, a, b ids) and route each half-plane test ([a x ·] and [x b ·] against the AB normal) through orient_sos-style canonical evaluation with an SoS tie-break, so an on-great-circle x resolves to a definite, traversal-order-independent side — exactly as the straddle gates already do. Thread the probe/edge ids from robust_crossing (sphere.rs:308-311) down into the call, plumbed from the existing ia/ib/PROBE_ID_* already passed at coverage.rs:482.

• Phase 3 — edge-great-circle fixtures + agreement. Extend the robust-PIP suite with deterministic edge-on-great-circle fixtures: the lon-45/lon-90 meridian boxes already in test_robust_pip_issue_11_meridian_box (sphere.rs:960-1001), plus tilted (non-axis-aligned) great circles built like test_orient_sos_breaks_coplanar_consistently (sphere.rs:575-588) so the degeneracy is not coordinate-luck. Assert agreement with the independent trig winding_inside oracle (sphere.rs:878-897) at on-edge probes, and brute-force argument/vertex-rotation invariance for robust_crossing directly.

• Phase 4 — verify the containment can relax (optional, flag-only). Note in the PR whether the node_straddles over-refinement at coverage.rs:442 is still needed once the disambiguation is exact, but do not change descent behavior in this PR without sign-off — raise it as a question.

Files likely touched

• src_rust/src/sphere.rs — on_minor_arc (265-268); signature/callers in robust_crossing (308-311); new tests in the tests module (after 1003).
• src_rust/src/coverage.rs — the single call site edge_crosses_probe (482) to pass identities; update the now-stale caveat comment (438-442).
• No Python surface change expected; rebuild via maturin develop --release and run cargo test / cargo clippy per the build conventions.

Acceptance criteria

• robust_crossing returns a deterministic, correct result for probe points lying exactly on an edge's great circle — no float-sign flips under argument or ring-vertex reordering.
• Tests pin the previously-flippable cases: the edge-on-great-circle fixtures classify deterministically and match the winding_inside oracle.
• The SoS decision is total (never returns an undecided/zero state) and antisymmetric, consistent with the orient_sos contract already asserted at sphere.rs:589-600.
• Existing robust-PIP and Polygon's malformed when crossing the prime meridian #11 regression tests stay green; no change to clean (non-degenerate) crossing behavior.

Questions for review (concrete, one-pass)

1. Approach — SoS-perturbation vs exact arithmetic. Mirror the existing f64+SoS orient_sos pattern (consistent with the codebase, the approach signed off in Support hemisphere+ polygons via S2-style edge crossing PIP #22, lowest surface area) — or use exact/extended-precision arithmetic for the on-arc test only? Recommendation: SoS, for consistency with the four gates. Confirm?

2. Resolve vs raise on degeneracy. The issue notes the current failure is silent. Should the hardened path always silently resolve to a definite side (matching the gates' behavior), or additionally surface a debug-assert/diagnostic when the on-arc test hits exact zero? Recommendation: silently resolve (no error), since the whole point of SoS is a consistent definite answer; add a debug_assert!-level invariant only.

3. Scope of the node_straddles containment. Leave the descent's over-refinement (coverage.rs:442) untouched in this PR (treat as orthogonal), or fold its relaxation in once disambiguation is exact? Recommendation: leave untouched here; track separately — relaxing descent fill is a behavior change deserving its own validation.

---

Generated by Claude Code

[espg]

Approach — SoS-perturbation vs exact arithmetic

SoS, for consistency with the four gates

Resolve vs raise on degeneracy

Resolve

Scope of the node_straddles containment. Leave the descent's over-refinement (coverage.rs:442) untouched in this PR (treat as orthogonal), or fold its relaxation in once disambiguation is exact? Recommendation: leave untouched here; track separately — relaxing descent fill is a behavior change deserving its own validation.

leave untouched here

Please also add benchmarks to assess impact of this change (we don't need benchmarks committed to main, just run and reported at the end of the PR as a comment)