Skip to content
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

[BUG] biconnected_components loses some edges - should we return only vertices ? #13

Closed
etiennedeg opened this issue Oct 19, 2021 · 9 comments
Labels
bug Something isn't working
Milestone

Comments

@etiennedeg
Copy link
Member

This is a repost of this issue, I think it deserves discussion on whether we should return edges instead of vertices.

Summary :

start=[1,1,2,2,2,3,4,4,5,5,7,7,8,8,9,9,10,10,12,12,1,2,3]
destination=[2,4,4,5,3,5,7,8,7,8,9,10,9,10,11,12,12,13,13,11,11,12,13]

graph_s=SimpleWeightedGraph(start,destination,collect(1:23))

bi_components= biconnected_components(graph_s)

graph_s has 23 edges, but only 19 are returned in the unique biconnected component.

etienneINSA : The error is here : the edge is added only if state.low[v] > state.depth[w], whereas it should be always added to the stack. I can make a PR, but I have an interrogation: Why do we return the biconnected components by their edges? As the subgraphs are induced, this is more easily defined by the vertices. Is there a good reason to do that, or would it be too breaking to change this behavior?

@etiennedeg etiennedeg added the bug Something isn't working label Oct 19, 2021
@jpfairbanks
Copy link
Member

I think this is a breaking API change, so I would rather fix the bug and possibly add an additional function that does biconnected_component_vertices or something that just computes the vertex set.

@gdalle
Copy link
Member

gdalle commented Nov 11, 2021

@etiennedeg
Copy link
Member Author

@jpfairbanks Wouldn't a new function be a bit redundant ? Or do you suggest to deprecate the old method ?

@simonschoelly
Copy link
Member

It is indeed a bit unfortunate that this method returns sets of edges (which may not even have the same edge type as the input graph) and not sets of vertices. In most cases a user will probably have to do some extra work to get something out of this edge set.

But as this is indeed breaking, I think that should be a different PR from the bug fix itself. @etiennedeg you mentioned that you already know a way to solve that bug, would you mind making a PR that fixes that bug, with some additional test that would cover that case?

@etiennedeg
Copy link
Member Author

Ok I'm doing it

etiennedeg added a commit to etiennedeg/Graphs.jl that referenced this issue Jan 31, 2022
@gdalle gdalle moved this to Todo in Graphs triage Jun 16, 2023
@gdalle gdalle removed this from Graphs triage Jun 16, 2023
@gdalle gdalle added this to the v1.9 milestone Jun 28, 2023
@gdalle gdalle moved this to Todo in Graphs triage Jul 3, 2023
@etiennedeg
Copy link
Member Author

Fixed by etiennedeg@ee06ccc

@github-project-automation github-project-automation bot moved this from Todo to Done in Graphs triage Jul 5, 2023
@gdalle
Copy link
Member

gdalle commented Jul 5, 2023

Was this fixed by a PR?

@etiennedeg
Copy link
Member Author

No, this was done when I started contributing to this repo, and did some wild commits (which I don't do nowadays). I closed because my fix was a two line fix, and is already in the codebase since more than a year, but feel free to take a look / reopen for discussion if you feel like it.

@gdalle
Copy link
Member

gdalle commented Jul 5, 2023

No worries! I like your wild side 🤣

@gdalle gdalle reopened this Jul 5, 2023
@gdalle gdalle closed this as completed Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Status: Done
Development

No branches or pull requests

4 participants