6

I have a grid based graph, where nodes and edges occupy cells. Edges can cross, but cannot travel on top of each other in the same direction.

Lets say I want to optimize the graph so that the distance covered by edges is minimized. I am currently using A* search for each connection, but the algorithm is greedy and does not plan ahead. Consider the diagram below, where the order in which connections are made is changed (note also that there can be multiple shortest paths for any given edge, see green and purple connections).

enter image description here

My intuition says this is NP-Complete and that an exhaustive search is necessary, which will be extremely expensive as the size of the graph grows. However, I have no way of showing this, and it is not quite the same as other graph embedding problems which usually concern minimization of crossing.

ddriver1
  • 703
  • 9
  • 16
  • This is related to min-cost multicommodity flows, which is NP-hard. I'm not sure of a direct reduction, though. – templatetypedef May 30 '14 at 19:12
  • Do you actually need the _optimal_ solution, or just a good one? Even if this is NP-hard, a great many such problems admit easy algorithms for _excellent_ solutions, just not the optimal ones. – phs May 30 '14 at 19:25
  • Ideally I would like to determine whether the problem is indeed NP-hard (I will look into its relationship with multicommodity flows the person above suggested). However, I would also be interested in knowing about the algorithms which provide excellent solutions – ddriver1 May 30 '14 at 19:36
  • "the distance covered by edges is minimised" -- this is ambiguous. Do you mean the total number of cells covered by one or more edges? – j_random_hacker May 30 '14 at 20:31
  • @j_random_hacker Good point. The distance covered is in terms of the length of each individual connection. This is different from your description, which would mean a cell containing two crossing edges would be no costlier than a cell with just one edge. To make it clear, when I use my A* algorithm, for each successive 'step' from one cell to the next, the cost of the connection is increased by 1. – ddriver1 May 30 '14 at 20:45

1 Answers1

0

You didn't really describe your problem and your image is gone, but your problem sounds like the minimum T-join problem.

The minimum T-join problem is defined on a graph G. You're given a set T of even size, and you're trying to find a subgraph of the graph where the vertices of T have odd degree and the other vertices have even degree. You've got weights on the edges and you're trying to minimise the sum of the weights of edges in the subgraph.

Surprisingly, the minimum T-join problem can be solved in polynomial time thanks to a very close connection with the nonbipartite matching problem. Namely, if you find all-pairs shortest paths between vertices of T, the minimum T-join is attained by the minimum-weight perfect matching of vertices in T, where there's an edge between two vertices whose length is the length of the shortest path in G.

The minimum T-join will be a collection of paths. If two distinct paths, say a->b and c->d, use the same edge uv, then they can be replaced by a->u->c and b->v->d and reduce the cost of the T-join. So it won't use the same edge twice.

tmyklebu
  • 13,171
  • 3
  • 25
  • 51
  • Not sure where the image went when you were here, but it seems to be up (at least for me). In this problem we start with a set of vertices, and have a set of edges we want to embed on the grid, but the weights are initially unknown. There are different combinations of ways to layout the edges. The image shows a sub-optimal ordering of embedding connections (on the left) and an optimal embedding (on the right). On the suboptimal embedding, the orange connection is embedded last, and the direct path is now blocked, so it must make take a longer route. – ddriver1 May 31 '14 at 02:06
  • @ddriver1: I get a link to http://i.stack.imgur.com/igEwd.png and that returns some XML document that's probably an error message. – tmyklebu May 31 '14 at 02:09
  • Strange, it seems to work for me. Does this link work for you? [link](http://imgur.com/KZQsobd) – ddriver1 May 31 '14 at 12:58
  • Probably a partial imgur outage. It's there now. So you've got a bunch of edges that you want to embed in a non-overlapping way? 'Cause that's way harder. – tmyklebu May 31 '14 at 14:08
  • Edge crossing is allowed, but only crossing, an edge can't otherwise overlap. We are tying to build up the embedding - first we start with a set of nodes and their location on the grid. Then we try and embed the edges. As the image shows, the ordering in which we fill up the space on the graph influences the connectivity of subsequent edges, since the space is gradually filled up with new edges. – ddriver1 May 31 '14 at 15:32
  • But you're trying to embed a graph in the grid, where the vertex locations are fixed. Pretty sure this is NP-hard even if the graph is just a collection of edges. – tmyklebu Jun 01 '14 at 00:10