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

Implement is_articulation to check if vertex is articulation point #387

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

thchr
Copy link
Contributor

@thchr thchr commented Jun 19, 2024

This factors out the DFS step from articulation into a separate function articulation_dfs! and then uses this new function to implement is_articulation(g, v) which checks whether v is an articulation point of g without necessarily computing all the articulation points.

The branching on isnothing(is_articulation_pts) in articulation_dfs! is a bit inelegant - as is the fact that articulation_dfs! doesn't mutate if is_articulation_pts === nothing, but it seemed the simplest way to avoid code duplication.

Aside from these additions, I revised the doc string of articulation(g) a bit (e.g., it 1. previously misleadingly stated that g had to be connected; it does not; and 2. it changed nomenclature from "articulation point" to "cut vertex" mid-sentence).

@thchr
Copy link
Contributor Author

thchr commented Jun 19, 2024

Timing-wise, is_articulation(g, v) appears to give a speed-up of about a factor of ~2 in cases I looked at, compared to v ∈ articulation(g):

julia> g = path_graph(5)
julia> articulation(g) # [2, 3, 4]
julia> @btime 2  articulation($g)   # 209.656 ns (8 allocations: 704 bytes)
julia> @btime is_articulation($g, 2) # 122.850 ns (4 allocations: 464 bytes)

julia> g = path_graph(15)
julia> articulation(g) # [2:14...]
julia> @btime 9  articulation($g)   # 453.853 ns (10 allocations: 2.16 KiB)
julia> @btime is_articulation($g, 9) # 245.286 ns (4 allocations: 624 bytes)

Copy link

codecov bot commented Jun 19, 2024

Codecov Report

Attention: Patch coverage is 98.21429% with 1 line in your changes missing coverage. Please review.

Project coverage is 97.30%. Comparing base (56e5604) to head (669093e).
Report is 4 commits behind head on master.

Files Patch % Lines
src/biconnectivity/articulation.jl 98.21% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #387      +/-   ##
==========================================
- Coverage   97.31%   97.30%   -0.02%     
==========================================
  Files         120      120              
  Lines        6954     6965      +11     
==========================================
+ Hits         6767     6777      +10     
- Misses        187      188       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@gdalle gdalle added the enhancement New feature or request label Jun 26, 2024
@thchr
Copy link
Contributor Author

thchr commented Aug 26, 2024

Bump.

@thchr
Copy link
Contributor Author

thchr commented Oct 31, 2024

Bump :)

Copy link
Member

@gdalle gdalle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, you were right to ping again

@@ -1,6 +1,6 @@
name = "Graphs"
uuid = "86223c79-3864-5bf0-83f7-82e725a168b6"
version = "1.11.1"
version = "1.11.2"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

merge default branch into this PR, the version has evolved since

src/biconnectivity/articulation.jl Outdated Show resolved Hide resolved
src/biconnectivity/articulation.jl Outdated Show resolved Hide resolved
Comment on lines +70 to +72
s = Vector{Tuple{T,T,T}}()
low = zeros(T, nv(g))
pre = zeros(T, nv(g))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the idea is to call is_articulation several times in a row for different vertices, these allocations might be reusable? Maybe we should expose articulation_dfs!?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that'd be alright with me also. The _dfs part is an implementation detail though, so maybe this should just be called is_articulation!, taking work-arrays for pre and low then? Let me know what you think and I'll change to that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, but then we should at the very least explain how to initialize these arguments (and ideally what they mean)

Copy link
Contributor Author

@thchr thchr Nov 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See also discussion in #407 (comment): maybe we should just be calling these work_buffer1 and work_buffer2 (adding some comments to explain in the code - or reassigning them to more aptly named variables) to avoid exposing unnecessary complications and implementation details to users.

src/biconnectivity/articulation.jl Show resolved Hide resolved
Comment on lines +85 to +89
if !isnothing(is_articulation_pt)
if pre[u] != 0
return is_articulation_pt
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain this shortcut in a comment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants