Skip to content

simplify bridge-searching expression #1460

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

Closed

Conversation

harssRajput
Copy link

  • simplification in expression. reduced 3 different checks to 2.
    current expression:
low[node] = min(low[node], tin[ancestor], low[to])

proposed expression:

low[node] = min(low[node], low[to])    // whether "to" is descendants or already visited ancestor (i.e. back-edge)
  • complete explaination

We can further improve the intuition behind the low[] array. We know that low[node] stores the lowest entry time of any node that is reachable from node, including via back edges. The tin[node] represents the time when node was first discovered during DFS.

When we encounter a back-edge from node to one of its ancestors (say ancestor), the earlier logic suggests we consider tin[ancestor] to update low[node]. However, we can simplify and strengthen this by observing that if ancestor can reach further up in the DFS tree (through its own back-edges), we can directly use low[ancestor] instead.

So instead of:

low[node] = min(low[node], tin[ancestor])

We use:

low[node] = min(low[node], low[ancestor])

This works because low[ancestor] already reflects the lowest reachable ancestor for ancestor, and since node can reach ancestor, it can also reach everything that ancestor can.

This simplification helps propagate the true lowest entry time more effectively through the DFS tree and back-edges.

Thus, the final update rule becomes:

low[cur] = min(low[cur], low[to])

for all adjacent to, whether they are descendants in the DFS tree or already visited ancestors (i.e., back-edges).

simplification in expression. reduced 3 different check to 2 only.
@mhayter
Copy link
Contributor

mhayter commented May 12, 2025

I very much appreciate the work you've put in, however, I don't believe the code is incorrect. It very much parallels the cut vertices article. Consequently, I don't think it makes sense to change it. With that said, I'm very impressed with your command of this algorithm. Please continue to contribute!

@mhayter mhayter closed this May 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants