Is there an algorithm faster than O(n2) for computing the costs only between every pair in a weighted non-cyclic graph, assuming I do not need the shortest paths but just the paths I would get if using simple BFS? I do not need the actual paths, only the costs of the paths. My current solution is just to do a BFS starting from each node also keeping track of the weights of the edges along the way but this is obviously O(n2) and I am wondering if it is possible to do any better.
No, there is no algorithm better then O(n2).
The algorithm will need to at least go over each pair. There are O(n2) possible pairs in the graph:
. Therefore the algorithm bottom boundary is = O(n2).
Related
There are two functions that I wish to minimize:
a. the number of "obstacles" on the path (assume each obstacle increases the cost); and
b. total number of edges between the source and the destination.
If I had to minimize just (a), I would have used Dijkstra's algorithm; if I had to minimize just (b), I would have used BFS.
But given that I have to minimize both, can I use Dijkstra's algorithm only? In other words, if I find the path with the least cost from the obstacles, does Dijkstra's algorithm also guarantee that the path length thus obtained (between source and destination) would be the shortest?
When discussing paths on weighted graphs, the term "shortest path" means the path with the lowest total cost. Think of the weights as distances. This is the path that Dijkstra's algorithm will find.
You can use any cost function you like, as long as the cost to get from one vertex to another is always positive or zero. As mentioned in comments, however, you can only minimize one function at a time. This is a general fact that has nothing to do with Dijkstra's algorithm.
The cost function that you seem to suggesting is perfectly fine -- the cost to move to a normal vertex is 1, while the cost to move to an "obstacle" vertex is higher. Dijkstra's algorithm is the appropriate way to find a path with lowest total cost.
So i found an old topic :
Algorithm for diameter of graph?
which they said the best solution for non sparse graph is O(V^3)
but can't we just use the BFS on each vertex and then find the maximum?
and this way the time complexity will be O(V*(V+E)) = O(V^2 + VE)
am i wrong? because if the number of edges is just a multiplicand of V then this would work better, right?
so i guess my question is :
what is the best time complexity for computing the graph's diameter as of now in 2018
is my method wrong? what am i missing here?
The matrix in question is non-sparse. So it gives a worst case E ~ (V^2)/2 edges. The solution mentioned will thus become O(V^2+V*(V^2)) for non-sparse matrixes.
If the matrix was sparse then it would indeed be faster than O(V^3).
Also given the graph is non-sparse, it is usually represented using adjacency matrix, for faster lookup times. Breadth First Search would thus take O(V^2). This done as you mentioned across all nodes will again lead to O(V^3) computational time complexity.
Finding the diameter can be done by finding all pair shortest paths first and determining the maximum length found. Floyd-Warshall algorithm does this in O(V^3) time. Johnson's algorithm can be implemented to achieve O(V^2 logV + VE) time.
I have a graph, I want to walk through the graph (not necessary through all vertices), always taking path with greates weight. I cannot go through same vertex twice, I stop if there are no more moves I can make. What is the complexity? I assume it's "n" (where n is number of vertices) but I'm not sure.
If you can't go through the same vertice twice, your upper bound for edge traversals is n.
It's easy to think of examples where that would be a tight bound (a single chain of vertices connected for example).
However, keep in mind that complexity is for a given algorithm, not a general task, you haven't described your algorithm or how your graph is organized, so this question doesn't have any meaning.
If for example the graph is a clique, perhaps picking the highest weight edge for each traversal would itself take n computation steps (if the edges are kept in an unsorted list kept in each vertice), making the naive algorithm O(n^2) in this case. Other representations may have different complexity, but require different algorithms.
EDIT
If you're asking about finding the path with greatest overall weight (which may require you in some traversals to pick an edge that doesn't have the highest weight), than the problem is NP-hard. If it had a polynomial algorithm, then you could take an unweighted graph and find the longest path (a known NP hard problem as jimifiki pointed), and solve it with that algorithm.
From Longest Path Problem
This problem is called the Longest Path Problem, and is NP-complete.
To expand on the title, I need all simple (non-cyclical) paths between all nodes in a very large undirected graph.
The most obvious optimization I can think of is that once I have calculated all the paths between a particular pair of nodes I can just reverse them all instead of recalculating when I need to go the other way.
I was looking into transitive closures and the Floyd–Warshall algorithm, but it looks like the best I could do if I went down that route would be to find only the shortest paths between all nodes.
Any ideas? Right now I'm looking at running a DFS on every node in the graph, which seems to me to be significantly less than optimal.
I don't understand the reasoning behind your idea that DFS is significantly less than optimal. In fact, DFS is clearly optimal here.
If you traverse the graph, limiting the branching only to vertices which haven't been visited in this branch so far, then the total number of nodes in the DFS tree will be equal to the number of simple paths from the starting vertex to all other vertices. As all of these paths are a part of your output, the algorithm cannot be meaningfully improved, as you can't reduce complexity below the size of the output.
There is simply no way to output a factorial amount of data in polynomial time, regardless of what the problem is or what algorithm you are using.
What is the Best order of traversing edges within Bellman-Ford algorithm,
in order to achieve a minimum number of iterations that are necessary?
If the graph is acyclic the best way is traverse the vertices in topological order. This means only one iteration of the algorithm is necessary.
For cyclic graphs without negative edges you can use a generic shortest path algorithm as described in this pdf (sssp.pdf) with a Fifo queue, this can visit fewer vertices than the standard Bellman-ford algorithm which loops over vertices and then edges. In practice the Fifo queue approach is often faster than using a priority queue (Dijkstra) as mentioned in this answer ( Are there faster algorithms than Dijkstra? ). However, a dis-advantage of this approach is the unlike the standard Bellman-ford algorithm this algorithm will not terminate if the graph has negative cycles.
We can't generalize the best order of traversing so that no. of iterations are minimum as best order of traversing will vary from graph to graph but yes you will get the Single Source Shortest Paths in at most |V|-1 iterations. No graph would require more than |V|-1 iterations and if distance further decreases after |V|-1 iterations then it means that graph contains a negative edge cycle.