Talk:Depth-first search

message: When talking about the iterative approach to dfs, the article mentions one of the differences with bfs is that:
"it delays checking whether a vertex has been discovered until the vertex is popped from the stack rather than making this check before adding the vertex"
That's a moot point, as dfs could have just as easily written with the discovered check happening before adding in the stack.  — Preceding unsigned comment added by 24.56.255.3 (talk) 11:57, 10 June 2019 (UTC)
thread_title:  Is this even relevant? 

message: Another more basic example should be given to start with, without the link from F to E.
Surely it would be more intuitive to put the letters in a different order
Something like
 
     A
  B  C  D
E F  G
Or maybe the order that the search would go?
     A
  B  E  G
C D  F
Opticyclic 16:33, 21 April 2006 (UTC)
replies: text: I disagree. Any algorithm which examines every vertex and every edge must be at least \mathcal{O}(E+V) overall, which DFS is. Therefore, DFS is asymptotically optimal. Did you have a different idea of optimality in mind? bbi5291 (talk) 16:55, 15 November 2009 (UTC)
replies: text: Actually, I guess it depends on the application. If we're searching for a path, DFS is obviously not optimal in many cases, especially if the graph is infinite. But it does give optimal solutions to many important problems such as finding strongly connected components and biconnected components. bbi5291 (talk) 17:18, 15 November 2009 (UTC)
thread_title:  Weird Example 

message: Why do we have TWO solutions, both of them iterative, creatings stacks, etc? It seems that in general, iterative approaches that have to heavily-manipulate stacks are well-suited to recursive approaches (at least - it is conceptually easier) - and that is certainly true here.
I'm definitely going to replace one of these algorithms with a recursive solution. I'd prefer to replace the second, it looks less intuitive. (Remember we're not here to give the best-optimised code, but to teach how it works - therefore the conceptually easier code is always the best on wikipedia). —EatMyShortz 11:46, 28 February 2006 (UTC)
thread_title:  Recursive solution? 

message: As much as I love python, it shouldn't be marked as pseudocode.
The second one was better, but still not pseudocode.
That's true. I changed it.  —Preceding unsigned comment added by Srrrgei (talk • contribs) 20:27, 3 May 2009 (UTC)
replies: text: Why is Python better suited than pseudocode in this article? I would prefer the pseudocode.  —Preceding unsigned comment added by 38.99.165.166 (talk) 19:53, 6 May 2009 (UTC)
replies: text: Some people are under the impression that Python is easy and anyone can learn it. Unfortunately, this isn't the case and is detrimental to anyone wishing to implement the algorithm in another language. Pseudo-code is preferred because it abstracts away the nasty details of a particular language.--OMouse (talk) 14:02, 8 December 2009 (UTC)
replies: text: True. Can someone change it to pseudocode? --Robin (talk) 14:17, 8 December 2009 (UTC)
replies: text:  False. the code is still correct. And if "some people are under the impression that Python is easy" than the example is clearly a good thing for them, right? or are you against people that think python is easy? if you miss the pseudo code, add one. i for one would welcome examples in every single language. Removing correct information from wikipedia page is vandalism in my humble opinion.  Here's the link to everyone how misses the examples http://en.wikipedia.org/w/index.php?title=Depth-first_search&oldid=351536941 (NOTE: it's very hard to find a good example of non-recursion example in python outside of the history in this article). create a new page for examples if you want, but do not trash contributions. Gcbwiki (talk) 04:11, 10 January 2011 (UTC)

text: I disagree that we should have examples in multiple languages. Wikipedia is not a code repository. One reason for using pseudocode rather than Python here is that (compared to most other languages) Python has or had unusually low limits on recursion depth that make a recursive version of DFS a bad idea, so you have to fake it with a stack instead. Pseudocode can just recurse and be simpler because of it. —David Eppstein (talk) 04:12, 10 January 2011 (UTC)
thread_title:  Pseudocode!=Python 

message: The different classifications of edges are briefly discussed here, but should perhaps be moved to a new article. Consider:
* Tree edge: an edge (u, v) where v was discovered by exploring edge (u, v);
* Back edge: an edge (u, v) where u is connected to one of it's ancestors, v;
* Forward edge: a non-tree edge (u, v) that connects a vertex u to a descendant v;
* Cross edge: any other edge where one vertex is not an ancestor of the other.
I think this distinction should be made in the interest of better explaining the ability of detecting cycles in a graph using topological sorting. --Stimpy 20:10, 17 December 2006 (UTC)
replies: text: By the way, cycle detection is not the same as topological sorting, and I'm not convinced it belongs in the topological sorting article at all any more than it would belong in articles about other algorithmic problems on DAGs. If it is there, it should be as a brief sentence explaining why the DFS based topological sort algorithm is correct rather than as a separate subsection. —David Eppstein 21:25, 17 December 2006 (UTC)
replies: text: I'm sorry, upon reviewing my comment I understand that I didn't make clear what I was suggesting. I emphasize that (un)directional edges should be moved to a separate article and that both DFS article and the topological sorting article point to it, hence bridging the 'gap' in understanding how topological sort can be used – together with the principles of the four edge classifications – to find cycles in a depth-first search tree in O(n) time. In none of the articles on the subject is this relationship properly explained, in my opinion. —Stimpy 22:11, 21 December 2006 (UTC)
thread_title:  Edges 

message: Either the "reverse postordering" section has an error, or I am
confused. Since "reverse postordering is the reverse of a
postordering, i.e. a list of the vertices in the opposite order of
their last visit", why is D not first in reverse postordering?
TJA  —Preceding unsigned comment added by 68.162.149.237 (talk) 17:10, 25 March 2008 (UTC)
thread_title:  reverse postordering 

message: Why is the cycle in the depth-first graph "A, B, D, F, E"? I don't understand its assumptions. It seems to me that unless you're going to put some sort of directionality on the edges, you'll get something like A, B, D, B, D...
You can't even get from D to F without revisiting B. Sure, B is a backtrack and you don't usually include those in the search order, but if this search was keeping track of what was previously in the path, it wouldn't get into a cycle in the first place. It would take some sort of memory to go from B to D the first time and B to F the second. This strikes me as an error. rspeer / ɹəədsɹ  06:49, 28 August 2008 (UTC)
thread_title:  A, B, D, F, E? 

message: I just noticed that there is no proof of the algorithm running time (big O) listed? I thought this was standard for graph algorithms?129.59.172.24 (talk) 22:55, 10 February 2009 (UTC)
replies: text: I guess it's omitted here because it's pretty obvious - each node is visited once, and each edge is traversed twice. It's worth spelling out, but I'm not quite sure where to put it or how to formalize it. Dcoetzee 23:15, 10 February 2009 (UTC)
thread_title: No proof?

message: Shouldn't DFS have to memorize branching_factor * depth nodes? Consider it visiting a node N expanding two non-goal leaf nodes A and B, after backtracking from A, information about N's remaining children is necessary to avoid running into A again, isn't it? And as this holds for every node visited, this would require to memorize O(branching_factor * search_depth) nodes, doesn't it?  —Preceding unsigned comment added by 78.49.51.103 (talk) 17:44, 19 April 2009 (UTC)
replies: text: In theoretical computer science, DFS remembers which nodes it's already seen, and therefore takes as much space as BFS. In the AI search literature, which is where the space comparison and the analysis in terms of branching factor comes from, DFS is used without remembering already-seen nodes, and so it needs only enough memory to keep track of the call stack, but in this setting it should be used in conjunction with iterative deepening to control the size of this stack. Probably the differences between TCS and AI usage of DFS are not made sufficiently clear in the article. —David Eppstein (talk) 18:01, 19 April 2009 (UTC)

text: No. In the canonical DFS algorithm each level of the "backtracking" stack formally contains two pieces of information: 1) the vertex itself, and 2) the outbound edge, which we traversed when we left the vertex. (Note that in some circumstances the second piece of information can be "derived" indirectly and thus does not have to be physically stored). Every time we backtrack to some previously visited vertex, we use that second piece of information to continue to explore the adjacency of that vertex at the point where we left off. That all there is to it. No need to store all previously visited neighbors. For this reason space complexity of DFS is O(depth). No need to involve the branching factor. 173.11.122.193 (talk) 17:31, 12 March 2014 (UTC)
thread_title: Worst Case Space Complexity

message: From the article:
 In these applications it also uses space O(|V| + |E|) in the worst case to 
 store the stack of vertices on the current search path as well as the set of already-visited vertices.
From the box:
 Worst case space complexity: O(h) where h is the length of the longest simple path in the graph.
These statements are contradictory.  I think the box needs to be changed to reflect O(|V| + |E|).  —Preceding unsigned comment added by 12.25.230.211 (talk) 21:15, 13 August 2009 (UTC)
replies: text: The former is correct for the non-recursive implementation, the latter is correct for the recursive implementation. I'll see if I can make this clear in the article. bbi5291 (talk) 17:04, 15 November 2009 (UTC)
thread_title: Worst Case Space Complexity Contradiction

message: I suggest we remove the "optimal" entry from the infobox. Its interpretation is confusing. For an algorithm which solves 1 problem, it is clear what optimal means, it means that the best lower bound for the problem matches the upper bound provided by the algorithm. It doesn't mean anything to say an algorithm is optimal unless you refer to the problem. Since DFS (and BFS) solve so many graph theoretic problems, its not clear what optimal means. Which problem's lower bound is being matched by DFS (or BFS)? (On the other hand, sorting is the problem solved by bubble sort, and it is entirely clear what it means for bubble sort to be non-optimal.) --Robin (talk) 23:48, 16 November 2009 (UTC)
replies: text: I agree that it is confusing and that its prominence at the top of the DFS article lends undue weight to the application of DFS to finding paths in graphs, when it has many other uses. I would be happy to see it removed. Even for a single-purpose algorithm, it is not clear whether the optimality refers to the quality of the solution it finds (what I believe to be the intention here) or the time it takes to find it. —David Eppstein (talk) 23:52, 16 November 2009 (UTC)
replies: text:  Yes, that's true. I had decision problems in mind, where there is no notion of quality of solution. An algorithm is either optimal for the given problem or not. But since the problems solved by DFS/BFS have many correct answers, the quality of the solution is important. So, does anyone object to the entry on optimality being removed from the infobox? --Robin (talk) 00:47, 17 November 2009 (UTC)
replies: text: I think the specific intent of this field is "does this algorithm find shortest paths"? E.g. see the "yes (for unweighted graphs)" entry in breadth-first search. —David Eppstein (talk) 04:03, 17 November 2009 (UTC)
replies: text:  I do find the BFS optimality note weird too. There are excellent shortest path finding algorithms available, why would one use an algorithm that isn't meant to be one? I think the "optimal" entry in both articles will confuse the average reader, who probably came here to use BFS/DFS for some particular application (like checking connectivity or topological sorting). Perhaps optimality can be discussed explicitly in the article somewhere, explaining whether it is optimal for some applications mentioned in the article. Keeping it in the infobox does seem to give it WP:undue weight. (As opposed to the algorithm's time and space usage, which are really important theoretically and practically.) --Robin (talk) 04:24, 17 November 2009 (UTC)

text: I guess the question should be, do we rip out the optimality field from the infobox altogether, or do we just fix the infobox template so that omitting that field means it isn't displayed and then leave it blank in this article (and I guess BFS). There are algorithms such as IDA* that really only are for finding paths, but even there the meaning of "optimal: yes" in a box near the top of the page is highly unclear. —David Eppstein (talk) 04:29, 17 November 2009 (UTC)
replies: text:  If you omit the field, it isn't displayed. However, I went through the list of pages on which this infobox appears, and the situation is quite sad. Apparently, Merge sort is optimal, but Heapsort is "never". Also, Radix sort is "exactly correct". Personally, I'm opposed to calling an O(n log n) sorting algorithm optimal, because the Ω(n log n) lower bound is proved in a different model of computation. I believe that the field "optimal" should just be removed from the template. I'm going to suggest this at the template's talk page Template_talk:Infobox_Algorithm. --Robin (talk) 04:50, 17 November 2009 (UTC)
thread_title:  Optimality 

message: This article needs pseudocode, not a langauage war. Would anyone object to outright removal of all of these language-specific examples? I don't think they add anything. I wouldn't be opposed to moving them to Wikibooks and linking; it is useful to have a reference implementation in your language of choice, but the present state of things obscures the point of this page, which, believe it or not, is to explain depth-first search. —Ben FrantzDale (talk) 12:51, 11 May 2010 (UTC)
replies: text: I agree. —David Eppstein (talk) 14:37, 11 May 2010 (UTC)
replies: text: I've just seen this article (after reading today's xkcd on the subject). I agree that the many coding examples overbalance the article and are unnecessary. AndrewWTaylor (talk) 15:47, 2 July 2010 (UTC)

text: This thread here at the end when another was already going at the top just adds to the fact that no one here is interested in the content, but just in adding more fuel to the language war. good content is good content. it's never too much if it's not interfering with the summary and main topics.  — Preceding unsigned comment added by Gcbwiki (talk • contribs) 04:12, 10 January 2011 (UTC)
thread_title:  Example explosion 

message: How is a two sentence lede section "too long"? Justin W Smith talk/stalk 14:36, 3 July 2010 (UTC)
replies: text: I boldly removed the "lead too long" template. Justin W Smith talk/stalk 15:01, 3 July 2010 (UTC)
thread_title:  "introduction may be too long"? 

message: Is line 24 of the iterative solution correct? Why is the pop required at this point?  — Preceding unsigned comment added by 202.81.18.30 (talk) 06:23, 1 August 2013 (UTC)
thread_title:  Is iterative solution correct? 

message: A back edge found only if w is discovered, not explored. The iterative version gets this right. The recursive has a bug. It will report cycles on many simple DAGs where both a node an its successor have an edge to the same third node. — Preceding unsigned comment added by 69.181.252.29 (talk • contribs) 
: The code tests if an edge is "explored" but never marks edges as explored. If "explored" means "labelled", then it seems to be ok only for undirected graphs. The non-recursive version (which is not solving the same problem, see the "return" in there) also appears to be for undirected graphs only. Someone with more time on their hands than I do should sort this out properly. As a general principle, even though DFS can classify the edges and this is useful in some applications, the edge classification is not required for the search and the procedure should not be written to rely on it. McKay (talk) 05:15, 10 September 2013 (UTC)
thread_title:  In recursive pseudo-code, back edge detection is wrong 

message: I noticed that there is a phrase in Vertex ordering - it is natural to consider this code in the order A B C D or A C B D, but not natural to use the order A B D C or A C D B. Is this a claim? I mean how does this sentence add anylokirockz 13:09, 17 May 2014 (UTC)
replies: text: ABCD and ACBD are orderings in which you could actually write that code as structured code (ACBD comes from switching which clause is the if and which is the else). The other two orderings would be possible for spaghetti code with gotos, but not as structured code, because the D clause comes between the if and the else. This part of the article is saying that reverse-postorder of the control flow graph matches the ordering that you would normally write the code. The claim that reverse-postorder matches the ordering of structured code probably does need a citation but this specific example doesn't. —David Eppstein (talk) 18:50, 17 February 2015 (UTC)
thread_title:  Needs citation? 

message: Is it possible to add the definitions for |V| and |E| in the Properties section; because of the 'rule': explain abbreviations where they appear? 
Corresponding paragraph:
In theoretical computer science, DFS is typically used to traverse an entire graph, and takes time Θ(|V| + |E|), [...] https://en.wikipedia.org/wiki/Depth-first_search
Averrhoa (talk) 09:30, 16 October 2015 (UTC)
thread_title:  Add abbreviation definition? 

message: The non-recursive pseudocode is unnecessary complicated and it is not from Kleinberg and Tardos as opposed to what is claimed.
"and not in stack" is not an operation you can perform on a stack and it is not even needed here. 
The innermost "if w is not labeled as discovered" is unnecessary too, since this condition is checked anyway in the while loop. 
At this stage you can simply push the node to the stack. Below is the exact pseudocode from Kleinberg and Tardos, Algorithm Design, page 93.
I don't know how to format things here so please someone repair this.
  DFS (s) :
  Initialize S to be a stack with one element s
  While S is not empty
    Take a node u from S
    If Explored[u] = false then
      Set Explored[u] = true
      For each edge (u, v) incident to u
        Add v to the stack S
      Endfor
    Endif
  Endwhile
94.222.108.200 (talk) 17:12, 10 August 2016 (UTC)
replies: text: Thanks for catching this. I believe the "not in stack" test turned this into something different from DFS; see http://11011110.livejournal.com/279880.html on some pitfalls in this area. I have restored the simpler pseudocode. —David Eppstein (talk) 17:47, 10 August 2016 (UTC)
thread_title:  Non-recursive pseudocode from Kleinberg and Tardos? 

message: I noticed that you removed one of the examples that I added here because it was "too specialized." Would this example be suitable for inclusion elsewhere in this article? Jarble (talk) 00:57, 11 July 2017 (UTC)
replies: text: Maybe, even in the same list of applications. But it's a bad choice for the top of the list, because we should start with the simple and generic applications (currently at the top) and then add more specialized ones. —David Eppstein (talk) 01:03, 11 July 2017 (UTC)
replies: text:  I was misled by Wikipedia's description of backtracking algorithms, which incorrectly conflates backtracking with depth-first search. Jarble (talk) 17:54, 12 July 2018 (UTC)
thread_title:  SLD resolution 

message: It's unclear to me why the iterative algorithm shown here has this difference with BFS, noted after the algorithm, that the test for having been visited is done after pop rather than before push.  This does not seem to be intrinsically needed by the algorithm.  DFS and BFS should only differ by the underlying structure (stack vs queue). --24.148.56.233 (talk) 01:03, 26 October 2019 (UTC)
replies: text: As already stated above, please see https://11011110.github.io/blog/2013/12/17/stack-based-graph-traversal.html —David Eppstein (talk) 02:10, 26 October 2019 (UTC)
replies: text: Sorry, not sure how I missed that the conversation was already going on elsewhere.  I'd add my voice to the people that argue that the version on Wikipedia should have the property that dfs and bfs only differ by the queue vs stack property (using what you call dfs2 on 222).  --24.148.56.233 (talk) 02:56, 27 October 2019 (UTC)
thread_title:  Iterative version: why pushing visited nodes?