-
Notifications
You must be signed in to change notification settings - Fork 41
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
Modernize graph_ops.hpp #711
Conversation
Signed-off-by: Elazar Gershuni <[email protected]>
WalkthroughThe changes involve modifications to the Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
📒 Files selected for processing (1)
- src/crab_utils/graph_ops.hpp (31 hunks)
🔇 Additional comments (49)
src/crab_utils/graph_ops.hpp (49)
25-25
: Excellent use of a constant for invalid vertex identifiers!Introducing the
invalid_vert
constant to replace the use of-1
for invalid vertex identifiers enhances code clarity and reduces potential errors. Great improvement!
32-35
: LGTM!The check against
invalid_vert
is now used consistently for invalid vertices.
87-91
: LGTM!The iterator increment and decrement operators are implemented correctly.
99-102
: LGTM!The
vert_const_range
constructor and iterator methods are implemented correctly.
126-126
: LGTM!The use of
invalid_vert
for skipping invalid vertices in the iterator comparison is correct.
152-152
: LGTM!The use of
invalid_vert
for skipping invalid vertices in the edge iterator comparison is correct.
179-185
: LGTM!The changes to use
invalid_vert
andItG::empty_iterator()
in theadj_list
class are correct.
190-190
: LGTM!The use of
invalid_vert
for checking invalid vertices in themem
method is correct.
219-225
: LGTM!The changes to use
invalid_vert
andItG::empty_iterator()
in theconst_adj_list
class are correct.
230-230
: LGTM!The use of
invalid_vert
for checking invalid vertices in themem
method is correct.
248-251
: LGTM!The use of
invalid_vert
for checking invalid vertices in thesuccs
method is correct.
254-257
: LGTM!The use of
invalid_vert
for checking invalid vertices in thepreds
method is correct.
261-264
: LGTM!The use of
invalid_vert
for checking invalid vertices in thee_succs
method is correct.
267-270
: LGTM!The use of
invalid_vert
for checking invalid vertices in thee_preds
method is correct.
292-292
: LGTM!The
elem
method implementation is correct.
294-294
: LGTM!The
lookup
method implementation is correct.
Line range hint
554-564
: LGTM!The
grow_scratch
function implementation looks good. The exponential growth strategy and initialization of new elements are handled correctly.
595-595
: LGTM!The use of
std::max
to compute the maximum edge weight during the join operation is correct.
650-653
: LGTM!The
strong_connect
function implementation looks good. The logic for computing strongly connected components is correct.
669-669
: LGTM!The use of
gsl::narrow
for narrowing conversion is appropriate here.
674-677
: LGTM!The logic for generating strongly connected components when a root node is found is correct.
681-681
: LGTM!The use of bitwise AND to clear the visited flag is correct.
687-688
: LGTM!The
compute_sccs
function implementation looks good. It correctly initializes the scratch space and callsstrong_connect
for each unvisited vertex.
696-697
: LGTM!The initialization of the stack and index variables is correct.
709-709
: LGTM!The
select_potentials
function implementation looks good. It correctly computes strongly connected components and runs the Bellman-Ford algorithm on each SCC.
730-730
: LGTM!The loop over strongly connected components in reverse topological order is correct.
741-741
: LGTM!The increment of the queue tail pointer is correct.
744-745
: LGTM!The loop over vertices in the current strongly connected component is correct.
760-760
: LGTM!The increment of the next queue tail pointer is correct.
774-775
: LGTM!The loop for checking the feasibility of the current strongly connected component is correct.
794-794
: LGTM!The
close_after_meet
function implementation looks good. It correctly partitions edges and runs the chromatic Dijkstra variant on each source vertex.
919-924
: LGTM!The
dijkstra_recover
function implementation looks good. It correctly runs Dijkstra's algorithm while avoiding the expansion of stable vertices.
993-993
: LGTM!The
repair_potential
function implementation looks good. It correctly initializes the distances and runs Dijkstra's algorithm to repair the potential.
1045-1045
: LGTM!The
close_after_widen
function implementation looks good. It correctly marks stable vertices and callsdijkstra_recover
for unstable vertices.
1069-1072
: LGTM!The
AdjCmp
struct implementation looks good. It correctly compares vertices based on their slack values.
1077-1077
: LGTM!The
NegP
struct implementation looks good. It correctly returns the negated potential value for a given vertex.
1083-1085
: LGTM!The
close_after_assign_fwd
function implementation looks good. It correctly computes the transitive closure of edges reachable from a given vertex.
1102-1103
: LGTM!The increment of the adjacent tail pointer is correct.
1106-1106
: LGTM!The sorting of immediate edges by increasing slack using
AdjCmp
is correct.
1109-1109
: LGTM!The loop over adjacent vertices is correct.
1120-1120
: LGTM!The increment of the reachable tail pointer is correct.
1129-1129
: LGTM!The loop for collecting adjacencies and clearing vertex flags is correct.
1198-1199
: LGTM!The
close_after_assign
function implementation looks good. It correctly callsclose_after_assign_fwd
for both forward and reverse directions.
1211-1212
: LGTM!The use of
GraphRev
to compute the closure in the reverse direction is correct.
109-109
: 🧹 Nitpick (assertive)Use
vert_id
for consistency and consider renaming the parameter.For consistency with the rest of the codebase, use
vert_id
instead ofvert_id
for theafter
parameter. Additionally, consider renamingafter
to a more descriptive name, such aslast_vert
, to clarify its purpose.- vert_const_range verts() const { return vert_const_range(gsl::narrow<vert_id>(perm.size())); } + vert_const_range verts() const { return vert_const_range(gsl::narrow<vert_id>(perm.size())); }Likely invalid or redundant comment.
623-623
: 🧹 Nitpick (assertive)Consider using
const auto&
for function parameters.To avoid unnecessary copying and maintain const-correctness, consider using
const auto&
for thel
andr
parameters in thewiden
function.- static graph_t widen(const auto& l, const auto& r, std::unordered_set<vert_id>& unstable) { + static graph_t widen(const auto& l, const auto& r, std::unordered_set<vert_id>& unstable) {Likely invalid or redundant comment.
603-603
: 🧹 Nitpick (assertive)Consider using
const auto&
for function parameters.To avoid unnecessary copying and maintain const-correctness, consider using
const auto&
for thel
andr
parameters in themeet
function.- static graph_t meet(const auto& l, const auto& r, bool& is_closed) { + static graph_t meet(const auto& l, const auto& r, bool& is_closed) {Likely invalid or redundant comment.
84-85
: 🧹 Nitpick (assertive)Consider using
vert_id
type for consistency.For consistency with the rest of the codebase, consider using the
vert_id
type instead ofvert_id
for the constructor parameter and theoperator*
return type.- explicit iterator(const vert_id _v) : v{_v} {} + explicit iterator(vert_id _v) : v{_v} {} - vert_id operator*() const { return v; } + vert_id operator*() const { return v; }Likely invalid or redundant comment.
30-30
: Verify that all uses of-1
for invalid vertices have been replaced.The constructor now initializes the
inv
vector withinvalid_vert
instead of-1
, which is a positive change. However, please ensure that all other occurrences of-1
used for invalid vertices throughout the codebase have been consistently replaced withinvalid_vert
.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores