So here is the problem:
Ignore problem 7, i blanked out irrelevant parts.
I already know that the answer to Problem 8 is 13 as stated in the picture.
But i dont know how to algorithmically come to this conclusion.
I know how to create a MST from a graph using Prims Algorithm, but I feel like there is a better way to quickly come up with an answer here.
As it says in this link :
This problem can be solved by many different algorithms. It is the topic of some very recent research. There are several "best" algorithms, depending on the assumptions you make:
A randomized algorithm can solve it in linear expected time.1
It can be solved in linear worst case time if the weights are small integers.2
Otherwise, the best solution is very close to linear but not exactly linear. The exact bound is O(m log beta(m,n)) where the beta function has a complicated definition: the smallest i such that log(log(log(...log(n)...))) is less than m/n, where the logs are nested i times.3
These algorithms are all quite complicated, and probably not that great in practice unless you're looking at really huge graphs. The book tries to keep things simpler, so it only describes one algorithm but doesn't do a very good job of it. I'll go through three simple classical algorithms (spending not so much time on each one).
So it is better to stick with Prim or Kruskal
Karger, Klein, and Tarjan, "A randomized linear-time algorithm to find minimum spanning trees", J. ACM, vol. 42, 1995, pp. 321-328.
Fredman and Willard, "Trans-dichotomous algorithms for minimum spanning trees and shortest paths", 31st IEEE Symp. Foundations of Comp. Sci., 1990, pp. 719--725.
Gabow, Galil, Spencer, and Tarjan, Efficient algorithms for finding minimum spanning trees in undirected and directed graphs. Combinatorica, vol. 6, 1986, pp. 109--122.
Related
I have two isomorphic graphs.
Given a self-complementary graph G, is there any faster algorithm to find the vertex mapping between G and its complement?
I'm thinking there should be a faster way because we know that the 2 graphs are both isomorphic and complementary.
EDIT
Sorry I shoudld've been more clear:
I already know of the VF2 algorithm which has time complexity of O(V^2) in the best case and O(V!·V) in the worst case. Which makes it slow to compute mappings for the large graphs (1k vertices, 500k edges) that I'm working with.
I was just asking if given this special case of the graphs being both isomorphic and complementary there exists a faster solution.
This is the isomorphism problem for self-complementary graphs.
It might be expected
that
the isomorphism
problem
would
in fact be easier
to tackle when
restricted
to self-complementary
graphs
or digraphs,
because
of their
strong
structural
properties.
It turns
out,
however [Colbourn
and
Colbourn
1978,
1979],
that
the isomorphism
problem
for self-complimentary graphs
is polynomially
equivalent to the general
isomorphism
problem;
we say that
it is
isomorphism
complete
. Even if we just want to know whether
a graph
or digraph
is self-complementary, the complexity is the same.
This
makes it improbable
that
there
will be any simple
and
quick test
for recognising
sc-graphs;
for
example,
comparing
the chromatic
polynomial
of a graph
with
that
of its
complement will not tell us whether
it is self-complementary
(see
1.59).
Recognition
and isomorphism
of self-complementary
graphs
therefore
take
on added
importance.
They
could
provide
a cure
for what
has been nicknamed
the isomorphism
disease,
and
even settle
the famous
(or notorious)
question
of whether
P is equal
to NP, as we shall
see.
p.97 of this article:
Self-complementary graphs and generalisations: a comprehensive reference manual.
Alastair Farrugia
University of Malta
August 1999
http://www.alastairfarrugia.net/sc-graph/sc-graph-survey.pdf
Is there an efficient algorithm to find the subgraph with the largest average degree (which may be the graph itself)?
The paper "Finding a Maximum-Density Subgraph" by Andrew Goldberg gives a polynomial-time algorithm for identifying such a graph. It looks like the algorithm makes logarithmically many calls to a max-flow algorithm on appropriately constructed graphs. From what I've read, it looks like the algorithm is just a binary search over the average degree where each guess is checked using a maximum flow on a standard graph construction. Most of the complexity appears to be in arguing why the construction is correct.
Hope this helps!
I'm curious as to what the most effective methods are to find the most optimal (or close to optimal) upper bound for the TSP using a MST. I'm trying to optimize my algorithms for speed, but I'm having trouble algorithmically computing "good" bounds after I find the MST. I know a base bound would be 2 x MST length, but this doesn't seem to be the best we can do. Any references or insight would be appreciated.
You should probably convert the MST into a tour, and that'll give you a bound less than 2 * MST length, in linear time. There is also an extension to MST, called Christofide's Algorithm that might be worth looking into as well.
Recommend taking a look at the Wikipedia page for TSP heuristics.
I would like to know a fast algorithm to find only the clique number(without actually finding the clique) of a graph with about 100 vertices.
I am trying to solve the following problem.
http://uva.onlinejudge.org/external/1/193.html
This is NP-complete, and you can't do it much better than actually finding the maximum clique and counting its vertices. From Wikipedia:
Clique problems include:
solving the decision problem of testing whether a graph contains a clique larger than N
These problems are all hard: the clique decision problem is NP-complete (one of Karp's 21 NP-complete problems),
If you can find the clique number in P, then the decision problem is answerable in P (you simply compute the clique number and compare it with N).
Since the decision problem is NP-Complete, finding the clique number of a general graph must be NP-Hard.
As already stated by others, this is probably really hard.
But like many theoretically hard problems, it can be pretty fast in practice with a good algorithm and suitable data. If you implement something like Bron-Kerbosch for finding cliques, while keeping track of the largest clique size you've found so far, then you can backtrack out of fruitless search trees.
For example, if you find a clique with 20 nodes in it, and your network has a large number of nodes with degree less than 20, you can immediately rule out those nodes from further consideration. On the other hand, if the degree distribution is more uniform, then this might be as slow as finding all the cliques.
Although the problem is NP-hard, the size of graph you mention is not any problem for today´s fastest maximum clique exact solvers (for any configuration).
If you are ready to implement the code then I recommend you read the papers connected with the family of algorithms MCQ, MCR and MCS, as well as the family BBMC, BBMCL and BBMCX. An interesting starting point is the comparison survey by Prosser [Prosser 12]. It includes explanation for a Java implementation of these algorithms.
Suppose I have 10 points. I know the distance between each point.
I need to find the shortest possible route passing through all points.
I have tried a couple of algorithms (Dijkstra, Floyd Warshall,...) and they all give me the shortest path between start and end, but they don't make a route with all points on it.
Permutations work fine, but they are too resource-expensive.
What algorithms can you advise me to look into for this problem? Or is there a documented way to do this with the above-mentioned algorithms?
Have a look at travelling salesman problem.
You may want to look into some of the heuristic solutions. They may not be able to give you 100% exact results, but often they can come up with good enough solutions (2 to 3 % away from optimal solutions) in a reasonable amount of time.
This is obviously Travelling Salesman problem. Specifically for N=10, you can either try the O(N!) naive algorithm, or using Dynamic Programming, you can reduce this to O(n^2 2^n), by trading space.
Beyond that, since this is an NP-hard problem, you can only hope for an approximation or heuristic, given the usual caveats.
As others have mentioned, this is an instance of the TSP. I think Concord, developed at Georgia Tech is the current state-of-the-art solver. It can handle upwards of 10,000 points within a few seconds. It also has an API that's easy to work with.
I think this is what you're looking for, actually:
Floyd Warshall
In computer science, the Floyd–Warshall algorithm (sometimes known as
the WFI Algorithm[clarification needed], Roy–Floyd algorithm or just
Floyd's algorithm) is a graph analysis algorithm for finding shortest
paths in a weighted graph (with positive or negative edge weights). A
single execution of the algorithm will find the lengths (summed
weights) of the shortest paths between all pairs of vertices though it
does not return details of the paths themselves
In the "Path reconstruction" subsection it explains the data structure you'll need to store the "paths" (actually you just store the next node to go to and then trivially reconstruct whichever path is required as needed).