2

I tried googling it up, but nothing of value pops up.

The graph:

  • is undirected.
  • is represented as directed graph with double edges.
  • may contain edges with negative weights.

I know I can use Bellman-Ford to solve this in the directed case, but with undirected edges it will just return single edges (2-cycles) as its output. I need to find a cycle of size > 2.

Also, the algorithm is supposed to have run-time complexity O(V*E) and memory complexity O(V).

Niklas B.
  • 92,950
  • 18
  • 194
  • 224
matt-pielat
  • 1,659
  • 3
  • 20
  • 33
  • "My method that uses Ford-Bellman algorithm doesn't work (obviously) as it returns single edges" This is not at all obvious, so please elaborate. Bellman-Ford can definitely be used to solve this problem. – Niklas B. Mar 18 '14 at 17:45
  • I don't have access to that function. It doesn't work properly for undirected graphs and I should either make my own similar method or use another algorithm. I tried with a sheet of paper and I can't see how **can** it work. I got stuck when two vertices kinda "pointed" at each other and were lowering weight every iteration. – matt-pielat Mar 18 '14 at 17:48
  • Your space-time constraints seem impossible. – John Dvorak Mar 18 '14 at 17:54
  • "I don't have access to that function" You seem to have to point out what you are allowed and what you are *not* allowed to do. Bellman-Ford *can* do it and it is most definitely the intended solution – Niklas B. Mar 18 '14 at 17:57
  • @JanDvorak Those are exactly the Bellman-Ford bounds. Not sure why that seems impossible to you – Niklas B. Mar 18 '14 at 17:58
  • @lavsprat: So you want to not find *any* cycle, but a cycle of size > 2? – Niklas B. Mar 18 '14 at 17:59
  • @NiklasB http://stackoverflow.com/questions/14785413/can-we-apply-bellman-ford-algorithm-to-undirected-graph – matt-pielat Mar 18 '14 at 18:00
  • @lavsprat Please check if my edit reflects your original problem – Niklas B. Mar 18 '14 at 18:03
  • @lavsprat: The problem I see here is that even then, if {A,B} is a negative edge, any path A -> B -> X -> B -> A will be a negative cycle of size > 2, if |w({B,X})| < |w({A,B})|. So unless this is what you want, I think you need to restate your problem entirely. Maybe using a restriction like "edges can only be used once", but then the problem is unlikely to be solvable using shortest-path algorithms (it will become a min-cost flow problem then). Maybe the problem author just wants you to realize that the problem is trivial to solve because of the 2-cycles. What is the source of the problem? – Niklas B. Mar 18 '14 at 18:06
  • It's my homework. I was told that my lecturer explicitly said, that 2-cycles are not acceptable for undirected graphs. – matt-pielat Mar 18 '14 at 18:14
  • Seems I have to make sure if it's really required from me to return "true" cycles. The problem **does** seem unsolvable with such time & memory constraints. – matt-pielat Mar 18 '14 at 18:24
  • @lavsprat: What is the definition of "true" cycle? – Niklas B. Mar 18 '14 at 18:29
  • @niklas I was thinking in terms of "for each edge, does there exist a path between its endpoints excluding the edge?", which is an order of magnitude too slow. Are you sure Bellman-Floyd can be used? – John Dvorak Mar 18 '14 at 18:37
  • @JanDvorak: It all depends on what constitutes a "cycle" in this scenario. – Niklas B. Mar 18 '14 at 18:40
  • @NiklasB. Basically (a,b) and (b,a) is the same edge. – matt-pielat Mar 18 '14 at 18:44
  • That's not what I asked. – Niklas B. Mar 18 '14 at 18:46
  • By "true" cycle I mean regular graph cycle whose implementation follows my previous statement. – matt-pielat Mar 18 '14 at 18:50
  • @niklas as I understand it, you are not allowed to reuse edges – John Dvorak Mar 18 '14 at 19:01
  • @JanDvorak That would be a simple cycle then. That also excludes 2-length cycles, so it makes sense – Niklas B. Mar 18 '14 at 19:04
  • @JanDvorak Yes. When edge (a,b) is used, both (a,b) and (b,a) are marked as such. – matt-pielat Mar 18 '14 at 19:05

1 Answers1

2

Looking at the Bellman-Ford algorithm, in step 2 you consider using every edge (u, v) to to find a shorter path to v and, if you see an improvement, you record it by setting predecessor[v] = u. This means that at each stage you know the predecessor of each node - so you can eliminate length two cycles by checking that predecessor[u] != v before you set predecessor[v] = u.

By eliminating these cycles you change the invariant of the induction - at each stage you are now finding the shortest route to u from s with at most i edges which does not include any length 2 cycles.

A cycle of length 3 or greater reachable from the source should still show up - the check for negative cycles looks for apparent improvements after you should have found every shortest path for lengths up to that necessary to visit every vertex.

Example:Consider G = {{A, B, C, D}, {AB=2, AC=2, BC=-3, BD=1, CD=1}}.

Updates, updating B then C then D:

A=0, B=C=D=infinity

A=0, B=2 from A, C=-1 from B, D=0 from C

A=0, B=1 from D, C=-2 from B, D=-1 from C

A=0, B=0 from D, C=-3 from B, D=-2 from C

A=-1 from C, B=-1 from D, C=-4 from B, D=-3 from C ...

Here is a proof that the distances will continue changing indefinitely in the presence of a negative cycle:

Suppose otherwise. Then there is an assignment of distances which is stable: no possible updating of any distance will decrease it. This means that the order in which edges are checked which might decrease a distance is irrelevant, since for this to be the case, every edge, when checked, leaves the distances unchanged.

Pick a point on a negative cycle and consider the path that goes along from that point until it wraps round and reaches itself again. Since checking the first edge in this path leaves everything unchanged, the distance at the far end of that edge minus the distance at the near end of that edge must be no more than the distance along the edge. Similarly, the distance two steps along the path minus the distance at the start of the path must be no more than the sum of the distances along the two edges concerned, or we would update the distance to the further of the two points. Carrying on, we work out that the distance at the end of the (circular) path must be no more than the start of the (circular path) plus the sum of the edges along that path, or something would have been updated. But the start and end of the path are the same point, because it is circular, and the sum of the distances along the edges is negative, because it is a negative cycle, so we reach a contradiction and there must in fact be some updating once we have checked all the edges along the circular path.

Neil
  • 24,551
  • 15
  • 60
  • 81
mcdowella
  • 19,301
  • 2
  • 19
  • 25
  • Unfortunately, your solution doesn't work. Take a look at [THIS](http://i.imgur.com/93rCnH2.png). Pink one is my starting point, blue numbers represent edges' weights, green arrows point at vertices' predecessors. – matt-pielat Mar 19 '14 at 14:06
  • @lavsprat You need an extra round to detect cycles, and you didn't check whether the relaxation you made would create a length-2 cycle. – David Eisenstat Mar 19 '14 at 15:36
  • I agree with David, and note that this follows the Wikipedia algorithm, except that I should have pointed out that the check to avoid 2-cycles needs to go into their step (3) as well as their step (2). I believe that the total number of rounds is the same with and without 2-cycle checking because for every undirected graph with a -ve cycle you can construct a directed graph without 2-cycles but with the same -ve cycle and the same timing for cycle detection by allowing only the directions needed to create and observe the cycle. – mcdowella Mar 19 '14 at 19:55
  • This solution doesn't work. Consider G = {{A, B, C, D}, {AB=2, AC=2, BC=-3, BD=1, CD=1}}. After running your algorithm (source A), the costs for vertices will stabilize on A=0, B=-1, C=-1, D=0. – kaspersky May 11 '15 at 14:30
  • @gg.kaspersky Your example data seems to work for me. I have added it as an example – mcdowella May 12 '15 at 05:39
  • @mcdowella, you "made" it work on this example. You chose a specific order of the edges to do the cost improvements. If you would use at each iteration the costs calculated in the previous iterations, (or the order of edges [AB, AC, BA, CA, BC, CB, BD, CD, DB, DC]) the algorithm will fail. You should also read the abstract of this paper: http://link.springer.com/chapter/10.1007/978-3-642-02270-8_7 – kaspersky May 12 '15 at 07:33
  • I have hand-checked your suggested edge-checking order and find that the distances appear to decrease indefinitely. I have added a proof of this to the end of my answer. Thanks for finding the paper, which I agree is some sort of warning - but I don't know of what. I don't think it is that the distances stop decreasing. I can't tell what it might be from the abstract of the paper. Can you find writeups of other work on the UNCCD problem? I don't suppose it could just be the distinction between noting that there is a negative cycle somewhere and actually finding the edges that make it up? – mcdowella May 12 '15 at 18:38