Talk:Eulerian path

message: "diconnected" is linked to the glossary but not in the glossary. I assume it means something along the lines of "strongly connected". Deco 05:56, 30 August 2005 (UTC)
replies: text: I'll change it to just "connected", since any type of connectivity implies strong connectivity when the in-degree and out-degree are equal at every vertex.  (Proof: if the digraph is connected but not strongly connected, there is a strong component that has edges coming in but no edges coming out.  Now count the heads and tails of edges inside that strong component to find a contradiction.) --Zero 11:14, 30 August 2005 (UTC)
thread_title:  Missing def 

message: Is a pentagram a unicursal star? --South Philly 03:39, 11 July 2006 (UTC)
thread_title: Pentagram

message: Why is an uneulerian path the only picture here?--Josh Rocchio 01:15, 29 September 2006 (UTC)
thread_title:  image? 

message: I'm missing a proof which proofs that if G a connected graph with an Euler tour if and only if every vertex of V(G) has an even degree. Is it somewhere else on the wiki? Otherwise I'd like to give one. --Noud 15:57, 29 July 2007 (UTC)
replies: text: I came to this article to find a proof, but unfortunately there is none. Please give yours! Thanks, --Abdull (talk) 09:17, 16 July 2008 (UTC)
thread_title:  Missing proof of Euler Tour 

message: The link to C++ source code http://tuxv.blogspot.com/2007/05/eulerian-path.html
should be removed since the source code is, beside a number of bugs, incorrect. It generates a path (or cycle) which visits each edge *at most* once and not *exactly* once, thus it is simply *not* Eulerian.  —Preceding unsigned comment added by 58.186.123.121 (talk) 18:20, 29 May 2008 (UTC)
thread_title:  Error in source code 

message: I added a mention of semi-Eulerian, because that's a not uncommon term used, but we should also have an example for that. While Pn of course works, perhaps something that's also simple, but slightly more interesting like :Image:Semi-Eulerian graph.png would be good. Unfortunately I don't know of any easy programs to label that more nicely and make it look like the other two images in the article. Can somebody help out? - Taxman Talk 14:15, 31 May 2008 (UTC)
thread_title:  Semi-Eulerian 

message: Please define self-intersecting path. Thanks, --Abdull (talk) 09:17, 16 July 2008 (UTC)
thread_title: self-intersecting path

message: Isn't there a faster recursive O(edges+vertices) algorithm than Fleury? I can't remember the name, but it was like start at any vertice (if we are finding a eulerian path, start at a vertice of odd degree), if the vertice has degree 0, add it to the circuit and return, else for each neighbour, delete the edge between the vertice and the neighbour and recurse on the neighbour. Rand0m011 (talk) 22:48, 18 April 2009 (UTC)
replies: text: I'm sure it can be done in O(#edges) time but we need to find a reference.  McKay (talk) 06:51, 19 April 2009 (UTC)

text: I may be a bit late, but I was just looking into this today and yes, here is a link .  Fleury's algorithm seems impractical because you have to check for bridges at each step.  That cycle finding algorithm is cool but kind of sneaky.  Is is something we want in the article? Alejandro Erickson (talk) 18:44, 4 June 2010 (UTC)
replies: text:  The "algorithm" at that link is wrong and useless.  But we need a linear time alg for this page. Zerotalk 10:10, 5 June 2010 (UTC)
thread_title:  Faster algorithm than Fleury 

message: So, how does the cycle finding algorithm have a O(n + m) time complexity?
It does
 3          pick an incident vertex v and remove (u,v) from E
|E| times. If the graph is represented with a linked list removing each edge costs O(|E|). If it's represented with a matrix removing an edge costs O(1), but picking an incident vertex costs O(|V|). So step 3 costs O(|E|) with a linked list graph, and it has to be done |E| times, so the time complexity can't be smaller than O(|E| ^ 2).
If it's with a matrix it can't cost less than O(|E| * |V|). What am I missing something here? Is there a quick way to delete an edge that I don't know? Shinra.Electric.Power.Company (talk) 22:12, 29 May 2011 (UTC)
replies: text: With an adjacency list structure, the while loop can be executed in constant time per incident edge plus constant overhead. This is not entirely trivial because of the requirement to "delete" each edge, which means that when (u,v) is deleted, (v,u) must be deleted too (I assume we are working on a undirected graph).  Simply marking the edge as deleted in a standard adjacency list structure won't do since the call find_tour(u) can be made many times for a single vertex u and we don't want to have to skip over the deleted edge multiple times. One solution is to represent the adjacency lists as doubly-linked lists, since these allow a node to be deleted in constant time when the position of the node is known.  This is also more tricky than it looks because the while loop has to be implemented in a way that doesn't break when recursive calls delete nodes from the list being scanned. The constant time overhead per call to find_tour() adds up to O(|E|+1) altogether since there is at most |E|+1 calls.  So the total cost is O(|E|+1).  The V is not required since the algorithm only scans one component of the graph. Some people would simplify O(|E|+1) to O(|E|) but I don't think that is correct. McKay (talk) 01:02, 30 May 2011 (UTC)
replies: text:  I don't understand exactly your method of deleting an edge in constant time, but it doesn't matter; the algorithm can definitely be done in O(|E|) (or O(|E|+1)) in other ways I didn't think before (using pointers to booleans for the edges and always picking the first edge in the list so you only go through the list once and it doesn't become a problem if some edges are marked). Shinra.Electric.Power.Company (talk) 01:07, 1 June 2011 (UTC)
replies: text:  See Doubly linked list#Removing a node for node deletion. Marking edges does not suffice because the whole list of neighbours is scanned multiple times for each vertex.  There is not just a single call to find_tour(u) for each vertex u like there is for other algorithms like depth-first search.  There can be many calls to find_tour(u) for the same vertex u active even at the same time, because the recursion follows a path in the graph that can repeatedly intersect itself. It is required for a good running time that the total for all the scans of the neighbours of u be proportional to the degree of u. So when one of the scans deletes an edge, the other scans must not see it at all even just to skip it. McKay (talk) 02:04, 1 June 2011 (UTC)
thread_title:  O( | V | + | E | ) complexity 

message: Does anyone know who made Fleury's algorithm?24.123.191.50 15:58, 16 November 2006 (UTC)
thread_title:  Pronunciation 

message: If, in a connected undirectional graph, all vertices are of degree 4, does there necessarily exist an Eulerian path with the additional criterion that every vertex is visited once before any are revisited? 2.25.121.100 (talk) 17:48, 22 June 2011 (UTC)
replies: text: No. An easy counterexample is three vertices in a triangle, each also having a loop connecting it to itself. 213.249.135.36 (talk) 19:27, 26 June 2011 (UTC)
thread_title:  Strange question I suddenly got curious about 

message: I'm not sure that the Graph-Magics websitehttp://graph-magics.com/articles/euler.php would count as a reliable source, but it provides a very simple algorithm to find an Eulerian path. It's equivalent to Hierholzer's algorithm, but it's easier to understand and implement:
:1. Start with an empty stack and an empty circuit (eulerian path).
:- If all vertices have even degree - choose any of them.
:- If there are exactly 2 vertices having an odd degree - choose one of them.
:- Otherwise no euler circuit or path exists.
:2. If current vertex has no neighbors - add it to circuit, remove the last vertex from the stack and set it as the current one. Otherwise (in case it has neighbors) - add the vertex to the stack, take any of its neighbors, remove the edge between selected neighbor and that vertex, and set that neighbor as the current vertex.
:3. Repeat step 2 until the current vertex has no more neighbors and the stack is empty.
:It also provides a similar algorithm for a directed graph.
:
:I also observe that if the top-of-stack (TOS) element can be accessed without popping it, the algorithm can be written as:
:1. Push the starting vertex onto the stack.
:2. If the TOS has no remaining edges, pop the vertex, and add it to the path. Otherwise, remove one of the edges, and push the vertex to which it connected.
:3 Repeat step 2 until the stack is empty.
:
:From this it follows that the sum of the number of vertices on the current stack and the path equals the number of removed edges plus one, which of course never exceeds the total number of edges plus one. Hence, the same memory can be used for the stack and the path by building them in opposite directions. (The same is also true of the original version of the algorithm, but is harder to see with all the pops and pushes.)
------
The Graph Magics algorithm is Hierholzer's algorithm with the following twist: instead of using any arbitrary already-encountered vertex with unused edges, it always uses the last one. This simplifies merging the sub-tour into the complete tour. All the vertices at the end of the current tour that have no remaining edges can be removed and put aside, and the new tour can then be appended to the end of the remaining current tour.
The following is equivalent, and is an algorithm that's very easily understood and implemented:
For a connected, undirected graph with zero or two odd-degree vertices:
:1. Allocate a memory buffer to store vertices in the path (represented as pointers or array indices) with its size equal to the number of edges plus one. Treat it as two initially-empty (last-in-first-out) lists: a head list, which starts at the beginning of the buffer and is built forward, and a tail list, which starts at the end of the buffer and is built backwards.
:2. Add the starting vertex for the path to the the head list. If there are odd-degree vertices, use one of them; otherwise, use any vertex.
:3. If the last vertex in the head list has no remaining edges, remove it from the head list, and add it to the tail list; otherwise, remove one of the remaining edges and add the vertex to which it connected to the head list.
:4. Repeat step 3 until all the edges have been removed (or equivalently, until the head and tail lists meet). This can be determined by simply decrementing a count of the remaining edges each time an edge is removed.
:5. Upon completion, the buffer will contain an Eulerian path.
If the number of edges isn't known, then the algorithm can be run until all vertices have been moved from the head list to the tail list, provided of course that the buffer is at least as large as the number of edges plus one. The tail list will then contain a Eulerian path. When run in this way, the algorithm is essentially identical to the original Graph-Magics algorithm. The only real difference is that the tail list is built backwards, so the original direction of the path is maintained.
Thinkatron (talk) 23:07, 9 August 2020 (UTC)
thread_title: Graph-Magics' Algorithm