BGL metric_tsp_approx time complexity?
Hi all, I ran metric_tsp_approx on a number of TSPLIB problems and got the following graph: http://goo.gl/iGYsH This would indicate the time-complexity is V^2 (V is the number of cities/vertices). However the documentation [1] says O(E log V). A complete graph has O(V^2) edges, so the documentation would indicate metric_tsp_approx is O( V^2 log V ) (?) The heavy lifting in metric_tsp_approx is done by prim_minimum_spanning_tree, which the documentation [3] also lists as O(E log V). However I then go to [4] and see that for an adjacency matrix prim's algorithm runs in V^2. Confused, Anders [1] http://www.boost.org/doc/libs/1_46_1/libs/graph/doc/metric_tsp_approx.html [2] http://www.boost.org/doc/libs/1_46_1/libs/graph/test/metric_tsp_approx.cpp [3] http://www.boost.org/doc/libs/1_46_1/libs/graph/doc/prim_minimum_spanning_tr... [4] http://en.wikipedia.org/wiki/Prim%27s_algorithm
On Tue, 7 Jun 2011, Anders Wallin wrote:
Hi all,
I ran metric_tsp_approx on a number of TSPLIB problems and got the following graph: http://goo.gl/iGYsH
This would indicate the time-complexity is V^2 (V is the number of cities/vertices). However the documentation [1] says O(E log V). A complete graph has O(V^2) edges, so the documentation would indicate metric_tsp_approx is O( V^2 log V ) (?)
The heavy lifting in metric_tsp_approx is done by prim_minimum_spanning_tree, which the documentation [3] also lists as O(E log V). However I then go to [4] and see that for an adjacency matrix prim's algorithm runs in V^2.
Are you using an adjacency matrix as your representation? Are your graphs dense? I don't remember what TSPLIB contains exactly -- are you using Euclidean problems that would turn into dense graphs? In that case, just reading the graph's distance matrix would take O(V^2), and so the complexity you are seeing is correct. -- Jeremiah Willcock
On Tue, Jun 7, 2011 at 4:45 PM, Jeremiah Willcock
On Tue, 7 Jun 2011, Anders Wallin wrote:
Hi all,
I ran metric_tsp_approx on a number of TSPLIB problems and got the following graph: http://goo.gl/iGYsH
This would indicate the time-complexity is V^2
Are you using an adjacency matrix as your representation?
Yes.
Are your graphs dense?
Yes they are complete graphs, so that is as dense as it gets I guess.
I don't remember what TSPLIB contains exactly -- are you using Euclidean problems that would turn into dense graphs? In that case, just reading the graph's distance matrix would take O(V^2), and so the complexity you are seeing is correct.
Right. My point is that the documentation for metric_tsp_approx and for prim_minimum_spanning_tree suggests that I should see O( E log (V) ) time complexity, which for complete graphs is O(V^2 log (V) ) when in fact I am seeing V^2 which is better. Does the BGL documentation say something about differing time complexity for adjacency_matrix and dense graphs? should it? Anders
On Tue, 7 Jun 2011, Anders Wallin wrote:
On Tue, Jun 7, 2011 at 4:45 PM, Jeremiah Willcock
wrote: On Tue, 7 Jun 2011, Anders Wallin wrote:
Hi all,
I ran metric_tsp_approx on a number of TSPLIB problems and got the following graph: http://goo.gl/iGYsH
This would indicate the time-complexity is V^2
Are you using an adjacency matrix as your representation?
Yes.
Are your graphs dense?
Yes they are complete graphs, so that is as dense as it gets I guess.
I don't remember what TSPLIB contains exactly -- are you using Euclidean problems that would turn into dense graphs? In that case, just reading the graph's distance matrix would take O(V^2), and so the complexity you are seeing is correct.
Right. My point is that the documentation for metric_tsp_approx and for prim_minimum_spanning_tree suggests that I should see O( E log (V) ) time complexity, which for complete graphs is O(V^2 log (V) ) when in fact I am seeing V^2 which is better. Does the BGL documentation say something about differing time complexity for adjacency_matrix and dense graphs? should it?
I do not believe the code uses any special-case algorithms for dense
graphs and uses a d-ary heap, so it probably actually is O(V^2 log_4 V);
you might not be hitting a large enough V to see the log term. It is odd
that the times follow the V^2 line so closely, though. Try changing the 4
on line 323 of
participants (2)
-
Anders Wallin
-
Jeremiah Willcock