Repository navigation
Hand a graph's nodes back in id order - #252
Merged
Gonzalo-Mier merged 2 commits intoSep 22, 2026
Merged
Gonzalo-Mier merged 2 commits into
Gonzalo-Mier merged 2 commits into
Conversation
getNodes() walked the unordered_map the nodes are kept in, so the vector came back in hash order: not the order the ids were handed out in, and not the same order on another build. The ids getEdges() reports index exactly that vector, so a caller resolving an edge through it joined the wrong pair of points -- silently, and differently on another machine. Measured on the bench's visibility graph: of 1911 edges, 933 appeared to run through the crop; resolved in id order, 2. Ids are dense over 0..numNodes()-1 because they are handed out as the node count at insertion and nodes are never erased, so the lookup cannot throw.
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Pull request overview
Fix Graph2D::getNodes() so the returned vector is ordered by node ID, allowing edge IDs to correctly index the corresponding nodes.
Changes:
- Build the node vector by iterating dense IDs through
index_to_nodes_. - Document the ordering contract in
Graph2D. - Add tests covering ordered nodes and empty graphs.
- Record the fix in the changelog.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/fields2cover/types/Graph2D.cpp |
Returns nodes in ID order with reserved capacity. |
include/fields2cover/types/Graph2D.h |
Documents the getNodes()[i] ordering guarantee. |
tests/cpp/types/Graph2D_test.cpp |
Verifies ID-to-node ordering and empty-graph behavior. |
CHANGELOG.md |
Documents the corrected node ordering behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Member
|
Thank you for finding all this issues @u33549 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Graph2D::getNodes()walked theunordered_mapthe nodes are kept in, so thevector came back in hash order: not the order the ids were handed out in, and not
the same order on another build. The ids
getEdges()reports index exactly thatvector, so a caller resolving an edge through it joined the wrong pair of points --
silently, and differently on another machine.
Measured on a visibility graph over a real field: of 1911 edges, 933 appeared to
run through the crop; resolved in id order, 2.
Ids are dense over
0..numNodes()-1because they are handed out as the node countat insertion and nodes are never erased, so the lookup cannot throw.
Adds a test that the ids
getEdges()reports index the vectorgetNodes()returns.