Comments (6)
I stumbled upon this issue when trying to convert a recursive DFS to iterative because my recursive DFS was running out of stack space.
The solution produced by this iterative version was wrong, completely different from the recursive implementation.
It’s fascinating how many primitive, basic algorithms are probably implemented incorrectly but work just well enough that no one ever cares or notices… reminds me of how so many text books have an incorrect or overflowing version of binary search.
People usually implement graph traversal first and only after that do they choose a FIFO queue for BFS or a stack for DFS as their data structure.
Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken https://research.google/blog/extra-extra-read-all-about-it-n...
def dfs(graph, source):
n = len(graph)
visited = set()
stack = [source]
while stack:
node = stack.pop()
if node in visited:
continue
visited.add(node)
for nbr in graph[node]:
stack.append(nbr)
So I don't know what all the confusion is about...The DFS orderings where the children visitation is swapped, etc, are all still equally correct and valid. That is - a DFS algorithm that randomized the children order is still valid.
IE for example, if you change the "for nbr in graph[node]" line to "for nbr in reversed(sorted(graph[node]))", the resulting DFS ordering is still valid and correct.
If you want them in a specific ordering, you'd usually have to force them into it in the algorithm. It rarely makes sense to try to force the structure to be ordered (as they do here) for the algorithm.
This often hits people who use graphs with pointers, or multiple threads, or ...
for nbr in graph[node]:
if not visited[nbr]:
into if node in visited: continue
visited.add(node)
for nbr in graph[node]:
stack.append(nbr)