Is backtracking absolutely necessary for cycle detection using DFS in directed graph?

Question

I came across this SO post where it is suggested that cycle detection using DFS in a directed graph is faster because of backtracking. Here I quote from that link:

Depth first search is more memory efficient than breadth first search as you can backtrack sooner. It is also easier to implement if you use the call stack but this relies on the longest path not overflowing the stack.

Also if your graph is directed then you have to not just remember if you have visited a node or not, but also how you got there. Otherwise you might think you have found a cycle but in reality all you have is two separate paths A->B but that doesn't mean there is a path B->A. With a depth first search you can mark nodes as visited as you descend and unmark them as you backtrack.

Why is backtracking essential?

Can someone explain with an example graph as what is meant in the given A->B example?

Finally, I have a DFS code for cycle detection in directed graph that does not use backtracking but still detects cycle in O(E+V).

public boolean isCyclicDirected(Vertex v){
  if (v.isVisited) {
    return true;
  }
  v.setVisited(true);
  Iterator<Edge> e = v.adj.iterator();
  while (e.hasNext()) {
    Vertex t = e.next().target;
    // quick test:
    if (t.isVisited) {
      return true;
    }
    // elaborate, recursive test:
    if (isCyclicDirected(t)) {
      return true;
    }
  }
  // none of our adjacent vertices flag as cyclic
  v.setVisited(false);
  return false;
}

Answer 1

Why you need to backtrack:

A -> B
^ \
|  v
D <- C

If you go A -> B and you don't backtrack, you'll stop there and you won't find the cycle.

Your algorithm does backtrack. You're just wrapping it in recursion so it might not quite look the way you expect. You recurse for one of the neighbours, if this doesn't find a cycle, that call returns and you try some other neighbour - this is backtracking.

Why you need to remember how you got to where you are:

A -> B
  \  ^
   v |
     C

The above graph has no cycle, but if you go A -> B, then A -> C -> B, you'll think there is if you don't remember the path.

As mentioned in the linked post, you can just set the visited flag to false before returning in your code (which I see you've now done) - this will act as remembering the path.

Answer 2

backtracking is not essential only if your graph doesn't have any case where you can get from node A to node B by two different paths. Your algo will detect a false positive in the case mentioned in the previous answer: A -> B \ ^ v | C But if you add backtracking your alto will work perfectly, even in the case above.

Answer 3

It's worth pointing out that this marking algorithm is an adaptation of the naive approach to linked list cycle detection that involves keeping track of each node visited so far. In this case the path followed by the recursion is treated as a linked list and the linked list algorithm is applied. The space complexity is what makes the algorithm sub-optimal for linked lists, since you need to hold a reference to each node in the list it is O(n). When you're applying this to a decently well-balanced graph howeever, the space complexity drops to O(logn). In the case where the graph is a tree, the space complexity degrades to O(n) but you get O(n) time complexity.

Also, the algorithm is still incorrect. Given a graph with nodes A and B and a single edge B->B, isCyclicDirected(A) will never detect the cycle.