-
-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PR for issue 32136: Add parameter 'induced' to connected_subgraphs_iterator
#35131
PR for issue 32136: Add parameter 'induced' to connected_subgraphs_iterator
#35131
Conversation
…-induced subgraphs
This is my first PR on GitHub. Not obvious for dummies... |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## develop #35131 +/- ##
=========================================
Coverage 88.57% 88.58%
=========================================
Files 2140 2140
Lines 397273 397415 +142
=========================================
+ Hits 351891 352052 +161
+ Misses 45382 45363 -19
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
I've sent you an invite for the team that has the permissions for that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not quite understand why you use here the dense datastructure rather than the sparse one. Since you need to iterate as fast as possible over the list of vertices the latter naively seems more appropriate to me.
# If vertex u has k active neighbors, we have 2^k possibilities. We | ||
# use the binary representation of n_cpt[i] to indicate which of the | ||
# k neighbors are selected. We omit the empty neighborhood which is | ||
# considered else where. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"else where" -> "elsewhere"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, this iterator was already using dense data structure, so I added the functionality in it. We can of course try to do the same with another data structure and compare performances, but this should be done in a separate issue/PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't the following naive algorithm (theoretically) optimal
- pick an edge e
- put e in H, merge its two ends in G and make a recursive call
- remove e from G, if the resulting graph is connected make a recursive call
Here by optimal, I mean that it explores no more edges than what is needed. Though, it does not seem delicate to make many efficient calls to connectedness + design an appropriate datastructure with efficient merge/removal.
Documentation preview for this PR is ready! 🎉 |
@videlec, I'm not sure what you want to compute with the algorithm you propose. With edge contraction, you may force the selection of some edges. For instance, if you have the triangle [1, 2, 3], after contracting edge (1, 2), you can either take both edges (1, 3) and (2, 3), or none of them. So I think you may miss some non-induced connected subgraphs. |
You indeed need to keep track edge multiplicities in the contracted graph. Once you contracted e = (1, 2), taking either (1, 3), (2, 3) or both makes no difference in G / e. "Choosing an edge e" should be replaced by "choose a non-empty subset of edges in the multiedge e". |
Does not seems easy to implement. This can be the object of a future PR. |
Sure. I would be delighted to know if there is a generation algorithm with O(1) delay!
I definitely agree :-) |
I don't think that O(1) delay is possible as you need to check connectivity after each edge deletion. |
Maybe an adaptation of : https://dl.acm.org/doi/10.1145/322234.322235? |
Fixes #32136