1

So I've been looking for an explanation of a 2-opt improvement for the traveling salesman problem, and I get the jist of it, but I don't understand one thing.

I understand that IF two edges of a generated path cross each other, I can just switch two points and they will no longer cross. HOWEVER - I do not understand how I can determine whether or not two edges cross.

To make my question clear, this is what I've done so far: (I did it in java)

  1. I have an object called Point that represents a city, with an x and y coordinate.
  2. I have a PointSet which has a set of Points contained in a List.
  3. I have a method for PointSet called computeByNN() which arranges the PointSet in a fairly short manner through a Nearest Neighbor algorithm.

So now I have a sorted PointSet (not optimal, but still short) and I want to do 2-opt on it. However, I don't know where to start. Should I check each and every line segment to see if they cross, and if they do, switch two points? I feel like that defeats the purpose of heuristics and it becomes a sort of brute force solution. Is there an efficient way to find if two segments of the tour cross?

I applogize if my question is not clear. I'll try to edit it to make it clearer if anyone needs me to.

u3l
  • 3,342
  • 4
  • 34
  • 51
  • 1
    Checking each in every edge is only `O(n²)`. A perfectly reasonable running time when approximating an NP-complete problem (which obviously has no known polynomial time exact solution). – Paul Sep 06 '13 at 18:08

1 Answers1

1

If you like you can create a look-up table to detect crossed edges. For n = 1000, order 10^12 entries is obviously too extravagant. However you probably are most worried about the shorter edges? Suppose you aimed to include edges to about √n of the nearest neighbors for each node. Then you are only in the realm of megabytes of space and in any case O(n^2) preprocessing. From there it's a heuristic, so good luck!

Also will mention this can be done on the fly.

clwhisk
  • 1,805
  • 1
  • 18
  • 17
  • Well ideally I'd like to fix all edges (even the long ones) that cross over as well. If you've seen the Concorde TSP solver, it is able to find ALL edges that cross, and replace them. I don't understand how it does it so quick though. However, i'll try it your way by checking just root(n) neighbors and see how it goes. Also what do you mean when you say that it can be done on the fly? (I'm a high school student really new to all of this, so forgive me for the stupid questions). – u3l Sep 07 '13 at 04:33
  • By on the fly I mean start with an entry table, and if a pair of edges actually occurs in your graph, only then store whether they cross or not. Sorry, I don't know TSP very well. It's only worth doing if you expected to test the same pairs over and over again. Since there isn't an obvious quick way to implement the √n part of my idea, I suggest you focus on how to check crossed edges. For instance, if the highest y value of edge A is less than the lowest of edge B, you don't need to perform any other checks. – clwhisk Sep 07 '13 at 05:17
  • It may be possible to reduce the time complexity by computing the shadow line segments each edge covers in the x and y dimensions. Then there is probably an algorithm to find those that intersect in under O(n^2). Then you only test crossing for those edges that can possibly intersect. – clwhisk Sep 07 '13 at 05:23
  • Okay, I see what you're saying now and i'll set your answer as accepted, although i'm going to try to find a better way to do this. If I find something, i'll post an answer to my question. Thanks for the help! This is some confusing stuff... – u3l Sep 07 '13 at 07:49
  • Does that make sense? It will take O(n log n) to sort the endpoints. Then you step through the endpoints left to right (O(n)) and maintain a list (O(n log n)) of edges that you have seen exactly one endpoint of so far. When it's time to remove an edge from this list, it can possibly cross only those edges in the list. And repeat this is each coordinate x, y... – clwhisk Sep 07 '13 at 16:45
  • http://www.win.tue.nl/~kbuchin/teaching/2IL55/slides/02line-segment-intersection.pdf http://www.lems.brown.edu/~wq/projects/cs252.html – clwhisk Sep 07 '13 at 17:01