Add metric closure function #390
Merged
Conversation
This file contains 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
mtreinish
force-pushed
the
metric-closure
branch
from
2683684 to
4205268
Compare
This commit adds a metric closure function to retworkx. The metric closure of a graph is the complete graph in which each edge is weighted by the shortest path distance between the nodes in the graph. This is the first step towards implementing the minimum steiner graph function because the first step for that is to compute the metric closure for the graph. Additionally, this function is entirely self contained to a new rust module steiner_tree.rs (which we'll eventually add the steiner_tree() function too) in the interest of showing the eventual organizational structure we want for Qiskit#300 (although having an algorithms namespace might make sense for Qiskit#300). In a separate PR addressing Qiskit#300 we should start to reorganize the rust code in lib.rs like this to make things easier to find. Partially implements Qiskit#389
mtreinish
force-pushed
the
metric-closure
branch
from
4205268 to
99a00b8
Compare
Pull Request Test Coverage Report for Build 1098108469
💛 - Coveralls |
georgios-ts
reviewed
Jul 20, 2021
4 tasks
The previous check for a disconnected graph only caught graphs with completely disconnected nodes and didn't detect all disconnected graphs. This commit fixes the logic by check the first node in the graph has a path to all other nodes.
Co-authored-by: Ivan Carvalho <[email protected]>
IvanIsCoding
approved these changes
Aug 3, 2021
mtreinish
added a commit
to mtreinish/retworkx
that referenced
this pull request
Aug 5, 2021
In Qiskit#390 one of the last changes made to the PR before merging was: Qiskit@3353b4b which changed the final loop constructing the metric closure edges from iterating over node indices and pulling the path from the hashmap for that index to just iterating over the hashmap. That however had the unintended side effect of introducing non-determinism to the output as the iteration order over a hashmap isn't guaranteed. This was causing failures in the steiner tree function as the metric closure edge order can affect the computed tree. This commit fixes this by switching back to using the node id order for the final output generation and adds a comment as to why.
mtreinish
added a commit
that referenced
this pull request
Aug 13, 2021
* Add steiner_tree function This commit adds a function to find an approximation of the minimum Steiner tree using the algorithm described in "A fast algorithm for Steiner tree" Kou, Markowsky & Berman (1981). https://link.springer.com/article/10.1007/BF00288961 This algorithm produces a tree whose weight is within a (2 - (2 / t)) factor of the weight of the optimal Steiner tree where t is the number of terminal nodes. Closes #389 * Add more tests * Switch to iterating over node indices in metric_closure In #390 one of the last changes made to the PR before merging was: 3353b4b which changed the final loop constructing the metric closure edges from iterating over node indices and pulling the path from the hashmap for that index to just iterating over the hashmap. That however had the unintended side effect of introducing non-determinism to the output as the iteration order over a hashmap isn't guaranteed. This was causing failures in the steiner tree function as the metric closure edge order can affect the computed tree. This commit fixes this by switching back to using the node id order for the final output generation and adds a comment as to why. * Fix release notes * Apply suggestions from code review Co-authored-by: georgios-ts <[email protected]> * Split out edge deduplication to separate function * Attempt to avoid cycles by using src and target in sort Co-authored-by: georgios-ts <[email protected]> * Remove input graph usage in edge deduplication Co-authored-by: georgios-ts <[email protected]> * Move steiner_tree() to Tree docs section * Add test case with equal distances This adds a test case with an input graph that has equal distances. It is a test based on a review comment [1] that was previously producing an incorrect output (that wasn't even a tree). After fixing the underlying issue it would be good to have this tested to ensure we don't regress on it in the future. [1] #392 (comment) Co-authored-by: georgios-ts <[email protected]>
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.
This commit adds a metric closure function to retworkx. The metric
closure of a graph is the complete graph in which each edge is weighted
by the shortest path distance between the nodes in the graph. This is
the first step towards implementing the minimum steiner graph function
because the first step for that is to compute the metric closure for the
graph.
Additionally, this function is entirely self contained to a new rust module
steiner_tree.rs (which we'll eventually add the steiner_tree() function
too) in the interest of showing the eventual organizational structure we
want for #300 (although having an algorithms namespace might make sense
for #300). In a separate PR addressing #300 we should start to
reorganize the rust code in lib.rs like this to make things easier to
find.
Partially implements #389