Count number of connected components more efficiently than length(connected_components(g))
#407
There are no files selected for viewing
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,26 +1,33 @@ | ||
| # Parts of this code were taken / derived from Graphs.jl. See LICENSE for | ||
| # licensing details. | ||
| """ | ||
| connected_components!(label, g, [search_queue]) | ||
|
|
||
| Fill `label` with the `id` of the connected component in the undirected graph | ||
| `g` to which it belongs. Return a vector representing the component assigned | ||
| to each vertex. The component value is the smallest vertex ID in the component. | ||
|
|
||
| ## Optional arguments | ||
| - `search_queue`, an empty `Vector{eltype(edgetype(g))}`, can be provided to avoid | ||
| reallocating this work array repeatedly on repeated calls of `connected_components!`. | ||
| If not provided, it is automatically instantiated. | ||
|
|
||
| ## Performance | ||
| This algorithm is linear in the number of edges of the graph. | ||
| """ | ||
| function connected_components!( | ||
| label::AbstractVector{T}, g::AbstractGraph{T}, search_queue::Vector{T}=Vector{T}() | ||
| ) where {T} | ||
| empty!(search_queue) | ||
| for u in vertices(g) | ||
| label[u] != zero(T) && continue | ||
| label[u] = u | ||
| push!(search_queue, u) | ||
| while !isempty(search_queue) | ||
| src = popfirst!(search_queue) | ||
| for vertex in all_neighbors(g, src) | ||
| if label[vertex] == zero(T) | ||
| push!(search_queue, vertex) | ||
| label[vertex] = u | ||
| end | ||
| end | ||
|
|
@@ -129,9 +136,74 @@ julia> is_connected(g) | |
| true | ||
| ``` | ||
| """ | ||
| function is_connected(g::AbstractGraph{T}) where {T} | ||
| mult = is_directed(g) ? 2 : 1 | ||
| if mult * ne(g) + 1 >= nv(g) | ||
| label = zeros(T, nv(g)) | ||
| connected_components!(label, g) | ||
| return allequal(label) | ||
| else | ||
| return false | ||
| end | ||
| end | ||
|
|
||
| """ | ||
| count_connected_components( g, [label, search_queue]; reset_label::Bool=false) | ||
|
|
||
| Return the number of connected components in `g`. | ||
|
|
||
| Equivalent to `length(connected_components(g))` but uses fewer allocations by not | ||
| materializing the component vectors explicitly. | ||
|
|
||
| ## Optional arguments | ||
| Mutated work arrays, `label` and `search_queue` can be provided to avoid allocating these | ||
| arrays repeatedly on repeated calls of `count_connected_components`. | ||
| For `g :: AbstractGraph{T}`, `label` must be a zero-initialized `Vector{T}` of length | ||
| `nv(g)` and `search_queue` a `Vector{T}`. See also [`connected_components!`](@ref). | ||
|
|
||
| ## Keyword arguments | ||
| - `reset_label :: Bool` (default, `false`): if `true`, `label` is reset to a zero-vector | ||
| before returning. | ||
|
|
||
| ## Example | ||
| ``` | ||
| julia> using Graphs | ||
|
|
||
| julia> g = Graph(Edge.([1=>2, 2=>3, 3=>1, 4=>5, 5=>6, 6=>4, 7=>8])); | ||
|
|
||
| length> connected_components(g) | ||
| 3-element Vector{Vector{Int64}}: | ||
| [1, 2, 3] | ||
| [4, 5, 6] | ||
| [7, 8] | ||
|
|
||
| julia> count_connected_components(g) | ||
| 3 | ||
| ``` | ||
| """ | ||
| function count_connected_components( | ||
|
There was a problem hiding this comment. I am a bit undecided if we should call this Ideally we use the same word everywhere. @gdalle Do you have an opinion on that? There was a problem hiding this comment. There's also There was a problem hiding this comment. If I had to pick I'd rather use There was a problem hiding this comment. Definitely no to I don't mind abbreviation from time to time, but lets go with |
||
| g::AbstractGraph{T}, | ||
| label::AbstractVector{T}=zeros(T, nv(g)), | ||
| search_queue::Vector{T}=Vector{T}(); | ||
| reset_label::Bool=false, | ||
| ) where {T} | ||
| connected_components!(label, g, search_queue) | ||
| c = count_unique(label) | ||
| reset_label && fill!(label, zero(eltype(label))) | ||
| return c | ||
| end | ||
|
|
||
| function count_unique(label::Vector{T}) where {T} | ||
| # effectively does `length(Set(label))` but faster, since `Set(label)` sizehints | ||
| # aggressively and assumes that most elements of `label` will be unique, which very | ||
| # rarely will be the case for caller `count_connected_components!` | ||
| seen = Set{T}() | ||
| for l in label | ||
| # faster than direct `push!(seen, l)` when `label` has few unique elements relative | ||
| # to `length(label)` | ||
| l ∉ seen && push!(seen, l) | ||
| end | ||
| return length(seen) | ||
| end | ||
|
|
||
| """ | ||
|
|
||
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
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
Oops, something went wrong.
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.
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 am all for performance improvements. But I am a bit skeptical if it is worth making the interface more complicated.
Almost all graph algorithms need some kind of of work buffer, so we could have something like in al algorithms but in the end it should be the job for Julia's allocator to verify if there is some suitable piece of memory lying around. We can help it by using
sizehint!with a suitable heuristic.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 agree that this will usually not be relevant; in my case it is though, and is the main reason I made the changes. I also agree that there is a trade off between performance improvements and complications of the API. On the other hand, I think passing such work buffers as optional arguments is a good solution to such trade-offs: for most users, the complication can be safely ignored and shouldn't complicate their lives much.
As you say, there are potentially many algorithms in Graphs.jl that could take a work buffer; in light of that, maybe this could be more palatable if we settle on a unified name for these kinds of optional buffers, so that it lowers the complications by standardizing across methods.
Maybe just
work_buffer(and, if there are multiple,work_buffer1,work_buffer2, etc?)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.
If we do this then all functions should take exactly one
work_buffer(possibly a tuple) and have an appropriate function to initialize the buffer. I think it is a major change which should be discussed separately.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.
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.
So I think if this is really important for your use case you can either
Experimentalsubmodule. Currently we don't guarantee semantic versioning there - this allows use to remove things in the future without breaking the API.But just to clarify - your problem is not that you are building graphs by adding edges until they are connected? Because if that is the issue, there is a much better algorithm.