Talk:Edmonds–Karp algorithm

Discussion

In the article, it is stated that "The distinguishing feature is that the shortest augmenting path is used at each step, which guarantees that the computation will terminate." However, as I understand it, the use of the shortest augmenting path ensure a faster running time than using breadth-running time. The terminiation of the computation is also ensured in the other algorithms based on Ford-Fulkerson, and has as such nothing to do with the breadth-first search. I will try to work on this entry at a later stage.--Kristjan Wager 09:52, 31 May 2005 (UTC)

The article is precisely correct! Please don't change it without discussion. --Zero 13:42, 31 May 2005 (UTC)

According to Cormen et al's Introduction to Algorithms, 2nd edition, the breadth-first search is done to reduce the search time from $O(E|f^{*}|)$ to $O(VE^{2})$ (see pages 658-663). It has nothing as do with ensuring that the algorithm terminates - this is ensured by the principles of the Ford-Fulkerson method.--Kristjan Wager 14:09, 31 May 2005 (UTC)

No, the $O(E|f^{*}|)$ bound only applies if the capacities are integers. If they are arbitrary real numbers, the Ford-Fulkerson method might fail to terminate and can even converge towards the wrong answer. See Ford-Fulkerson algorithm. --Zero 20:08, 31 May 2005 (UTC)

Ok, thank you for clearifying. While I was aware of the problems with Ford-Fulkerson in regards to real numbers, I was unaware that Edmonds-Karp fixed it. Interesting that Cormen et al didn't mention that aspect. I think I need to read the original article. --Kristjan Wager 07:34, 1 Jun 2005 (UTC)

In the figure: Ek-flow 4.png, there is an arrow upside down, please correct it.

The arrow is drawn correctly. What happens here is that flow is "sent back" from E to D. The flow that was going from D to E is redirected to go to F. Klem fra Nils Grimsmo 15:18, 20 November 2006 (UTC)

There is a small mistake in the pseudocode for the EdisonKarp algorithm. The flow returning is not computed correctly. It must be

...
while v ≠ s
u := P[v]
F[u,v] := F[u,v] + m
F[v,u] := F[v,u] - m
v := u
...

The net flow must be zero. --85.176.154.47 00:00, 24 January 2007 (UTC)

Oops. Thank you for notifying! Klem fra Nils Grimsmo 06:56, 24 January 2007 (UTC)

I believe there is another error in the pseudo code.

In the Breadthfirstsearch you do:

if (C[U,v] - F[u,v] > 0 and...)

But that is not a correct computation of the residual capacity. I believe it must be

if (C[U,v] - F[u,v] + F[v,u] > 0 and...)

Because a flow in one direction will increase the capacity in the other.

Note how values are updated when backtracking the path. The net flow is maintained. Skew symmetry is upheld. Klem fra Nils Grimsmo 20:29, 25 March 2007 (UTC)

At the end of the example it says that the minimal cut partitions the nodes into "sets {let A =6,B,C,E} and {D,F,G}, with the capacity c(A,D) + c(C,D) + c(E,G) = 3 + 1 + 1 = 5." But isn't the capacity here missing edge (D,E) with c(D,E) = 2 ? The capacity of the cut would then be 7 instead of 5. —Preceding unsigned comment added by 134.60.236.119 (talk) 15:15, 23 October 2007 (UTC)

No, the capacity is five. You should only count edges from the source set S to the sink set T. edge D,E is from T to S, and therefore does not increase the capacity. ArrowmanCoder (talk) 01:40, 20 February 2009 (UTC)

You state that "...and independently by Jack Edmonds and Richard Karp in 1972 (discovered earlier).". Well, that is usual in any science. Did anybody ask Dinic at what point in time he discovered the algorithm that is attributed to Edmonds and Karp? If not, then the remark "(discovered earlier)" should be removed. —Preceding unsigned comment added by 130.237.222.140 (talk) 14:52, 1 October 2008 (UTC)

Minimum Cut

In the example can you explain why that's the minimum cut and how you find it? —Preceding unsigned comment added by 151.68.39.88 (talk) 11:56, 8 February 2010 (UTC)

Pseudocode too detailed

I think this pseudocode is way too detailed. It is so detailed that it looks like an actually programming language. What do others think? Bender2k14 (talk) 16:42, 19 July 2011 (UTC)

I agree, and I think the Java and C are inappropriate for Wikipedia, which is not supposed to be a software library. Zero^talk 19:35, 19 July 2011 (UTC)

I disagree, it's refreshing to have the details of the algorithm presented. Many algorithms are sensitive to such details - the precise order in which "visited arrays" are updated, edge cases, etc. In this case, I recently improved the pseudocode to terminate once a shortest augmenting path from s to t is found. Without the details, other implementers may make the same mistake by iterating until the BFS queue is empty.

Should BreadthFirstSearch take F as a parameter?

Or am I missing something?

Damix 217.202.48.196 (talk) 23:42, 10 September 2011 (UTC)

Fatest pipe heuristic

Edmonds Karp is sometimes implemented using fatest path instead of shortest path. This has a runtime of O(|E|^2*logC) with C being the max flow. (for sparse graphs it's O(|E|logC*(|E|+|V|log|V|)) using Dijkstra). I guess |V| rarely much larger than logC, but perhaps the variation should be mentioned for completeness? — Preceding unsigned comment added by Thomasda (talk • contribs) 00:12, 28 February 2012 (UTC)

Edge weights must be: non-zero? positive?

Will this algorithm work correctly for edge weights of zero? If so, will the result always, sometimes, or never include those edges in the min-cut?

Will the algorithm work correctly if edge weights are negative?

Thanks,128.112.139.195 (talk) 21:28, 16 July 2012 (UTC)

Push and pop

The pseudocode uses "push" and "pop" for the queue handling. Push is fine, but pop (LIFO) will result in an algorithm that is extremely slow compared to shifting (FIFO). — Preceding unsigned comment added by 94.255.217.210 (talk) 21:16, 18 October 2012 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Edmonds–Karp algorithm. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20061005083406/http://www.cis.upenn.edu/~wilf/AlgComp3.html to http://www.cis.upenn.edu/~wilf/AlgComp3.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:57, 17 September 2017 (UTC)

Incorrect pseudo-code for the breadth-first-search part

It seems to me that the search can and should stop as soon as the sink node is reached. Indeed, all later processing is superfluous, as pred[t] can only be set once in each search. As it is now, the search stops when the queue is empty. In the first pass, that happens only after all nodes reachable from the source have been visited. JohannDeneux (talk) 15:45, 22 February 2020 (UTC)

I agree - each entry `pred[i]` is set exactly once, and set to the predecessor on the shortest path. So continuing the loop is completely unnecessary. I'll fix it soon. -- Anonymous — Preceding unsigned comment added by 73.153.188.27 (talk) 00:04, 6 September 2023 (UTC)

Unnecessary Edge Update in the Pseudocode

The pseudocode mentions that each edge must have a back-flow variable, and updates the back-flow near the very end of the algorithm. But the back-flow values only ever set, they're not used in finding a next shortest augmenting path or its flow, or in computing the total flow. So they look unnecessary - like someone just copied from the earlier Ford-Fulkerson algorithm page. If it's not important to the algorithm then all references to back-flow in the pseudocode should be eliminated. -- Anonymous