Conversation
…e edge A path here is a sequence of nodes, so two routes that differ only in which of several edges between the same pair they take are the same path. `yen` reports the cheaper edge and never the others, and so returns fewer paths than asked for on such a graph. That is consistent, but it is not what someone counting routes expects, and nothing said it. Document it, and document the way round it: carrying the edge a node was reached by inside the node makes the routes distinct, and both are then found. That needs nothing from this crate, and is worth writing down because the shape of the answer is not obvious from the signature. Tests cover the graph from the report and the same situation in the middle of a longer path, along with the suggested modelling.
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.
Closes #516.
You suggested there either describing the kind of graph that can be represented, or finding a backward compatible way to return edge ids. This does the first, and shows that the second is already available to the caller without a change here.
What is documented
A path is a sequence of nodes, so two routes differing only in which of several edges between the same pair they take are the same path. Where more than one edge joins two nodes the cheaper is taken, and the others are never reported — so on @HellOwhatAs's graph there is one path from
AtoB, and asking fork = 2returns one:That behaviour is consistent, and it is what
dijkstradoes too, but nothing said so and it is not what someone counting routes expects.And the way round it
When the individual edges matter, putting the edge a node was reached by into the node makes the routes distinct, and both are then found:
This needs nothing from the crate — it is the caller's choice of node type. Worth writing down, because the shape of the answer is not obvious from the signature, and it gives the reporter what they were after.
Tests
The graph from the report, the same situation in the middle of a longer path, and the suggested modelling. 295 tests pass, clippy and rustfmt clean.
Documentation only; no code changes.
I have not touched the other option you raised — returning ids alongside edges, with
(start, end)as the default. That is a larger API question and this does not foreclose it; if you would rather have that, say so and I will close this.