For SSSP on a graph, G=(V,E,W) to find the shortest weight path, d[s,t] from a source vertex, s to a destination vertex, t we run Bellman Ford only terminating once
d[s,v] <= d[s,u] + w(u,v) for all edges (u,v)
Assumption of no negative cycle assures that d[s,s] = 0
To formulate this as a linear programming problem, we write
max d[s,t] subject to d[s,v] <= d[s,u] + w(u,v) for all edges (u,v) and d[s] = 0
What I don't understand is why this is a maximization problem. Are we not minimizing the path weights? How are they equivalent?
Related
Question
I have a question about this problem:
Given an directed graph that contains N vertices and M edges, please determine that "there is a path from vertex i to vertex j for all 1 <= i, j <= N".
I want to solve for N <= 500, M <= 250000.
I found the naive pathfinding algorithm with dfs but the time complexity is O(N^2 M), so it is very slow.
Please tell me the efficient algorithm to solve it.
Example
For example, if this graph is given:
The answer is NO because there isn't a path from 4 to 1.
The following algorithm can me implemented with O(N+M) complexity.
Take any vertex u. Use flood fill algorithm to reach other vertices. If any vertex is not reachable, return NOK.
Now do the same, but go to the opposite direction. If any vertex is not reachable, return NOK.
Return OK. (Here we know that there is a path from any vertex v to u because of [2], and there is a path from u to any vertex w because of [1].)
I read the pseudocode of the floyd warshall algorithm
1 let dist be a |V| × |V| array of minimum distances initialized to ∞ (infinity)
2 for each vertex v
3 dist[v][v] ← 0
4 for each edge (u,v)
5 dist[u][v] ← w(u,v) // the weight of the edge (u,v)
6 for k from 1 to |V|
7 for i from 1 to |V|
8 for j from 1 to |V|
9 if dist[i][j] > dist[i][k] + dist[k][j]
10 dist[i][j] ← dist[i][k] + dist[k][j]
11 end if
But it just uses one dist matrix to save distances.
I think there should be n dist matrixes, where n is the number of vertexes,
Or at least we need two dist matrixes.
one stores the current shortest path within vertexes k-1,
the other stores the shortest path within vertexes k,
then the first one stores shortest path within k+1,
....
How can we just store the new shortest path distances within vertexes k in original matrix for distances within vertexes k-1?
this picture shows we need D0, D1, D2....D(n)
You're right in the sense that the original formula requires that calculations for step k needs to use calculations from step k-1:
That can be organized easily if, as you say, first matrix is used to store values from step k-1 second is used to store values from k, the first one is used again to store values from k+1 etc.
But, if we use the same matrix when updating values, in the above formula we might accidentally use instead of if value for index i,k has already been updated during the current round k, or we might get instead of if value for index k,j has been updated. Won't that be a violation of the algorithm, as we are using the wrong recursive update formula?
Well, not really. Remember, Floyd-Warshall algorithm deals with "no negative cycles" constraint, which means that there is no cycle with edges that sum to a negative value. This means that for any k the shortest path from node k to node k is 0 (otherwise it would mean that there is a path from k to k with edges that sum to a negative value). So by definition:
Now, let's just take the first formula and replace j with k:
And then let's replace in the same formula 'i' with 'k':
So, basically, will have the same value as and will have the same value as , so it doesn't really matter whether these values are updated or not during the cycle 'k' and so you can update the same matrix while reading it without breaking the algorithm.
You are partially correct here.
The output of Floyd Warshall Algorithm(i.e the NxN matrix) DOESN'T help to reconstruct the actual shortest path between any two given vertices.
These paths can be recovered if we retain a parent matrix P, such that it stores the last intermediate vertex used for each vertex pair (x, y). Say this value is k.
The shortest path from x to y is the concatenation of the shortest path from x to k with the shortest path from k to y, which can be reconstructed recursively given the matrix P.
Note,however, that most all-pairs applications need only the resulting distance matrix.These jobs are what Floyd’s algorithm was designed for.
I have some degenerate tree (it looks like as array or doubly linked list). For example, it is this tree:
Each edge has some weight. I want to find all equal paths, which starts in each vertex.
In other words, I want to get all tuples (v1, v, v2) where v1 and v2 are an arbitrary ancestor and descendant such that c(v1, v) = c(v, v2).
Let edges have the following weights (it is just example):
a-b = 3
b-c = 1
c-d = 1
d-e = 1
Then:
The vertex A does not have any equal path (there is no vertex from left side).
The vertex B has one equal pair. The path B-A equals to the path B-E (3 == 3).
The vertex C has one equal pair. The path B-C equals to the path C-D (1 == 1).
The vertex D has one equal pair. The path C-D equals to the path D-E (1 == 1).
The vertex E does not have any equal path (there is no vertex from right side).
I implement simple algorithm, which works in O(n^2). But it is too slow for me.
You write, in comments, that your current approach is
It seems, I looking for a way to decrease constant in O(n^2). I choose
some vertex. Then I create two set. Then I fill these sets with
partial sums, while iterating from this vertex to start of tree and to
finish of tree. Then I find set intersection and get number of paths
from this vertex. Then I repeat algorithm for all other vertices.
There is a simpler and, I think, faster O(n^2) approach, based on the so called two pointers method.
For each vertix v go at the same time into two possible directions. Have one "pointer" to a vertex (vl) moving in one direction and another (vr) into another direction, and try to keep the distance from v to vl as close to the distance from v to vr as possible. Each time these distances become equal, you have equal paths.
for v in vertices
vl = prev(v)
vr = next(v)
while (vl is still inside the tree)
and (vr is still inside the tree)
if dist(v,vl) < dist(v,vr)
vl = prev(vl)
else if dist(v,vr) < dist(v,vl)
vr = next(vr)
else // dist(v,vr) == dist(v,vl)
ans = ans + 1
vl = prev(vl)
vr = next(vr)
(By precalculating the prefix sums, you can find dist in O(1).)
It's easy to see that no equal pair will be missed provided that you do not have zero-length edges.
Regarding a faster solution, if you want to list all pairs, then you can't do it faster, because the number of pairs will be O(n^2) in the worst case. But if you need only the amount of these pairs, there might exist faster algorithms.
UPD: I came up with another algorithm for calculating the amount, which might be faster in case your edges are rather short. If you denote the total length of your chain (sum of all edges weight) as L, then the algorithm runs in O(L log L). However, it is much more advanced conceptually and more advanced in coding too.
Firstly some theoretical reasoning. Consider some vertex v. Let us have two arrays, a and b, not the C-style zero-indexed arrays, but arrays with indexation from -L to L.
Let us define
for i>0, a[i]=1 iff to the right of v on the distance exactly i there
is a vertex, otherwise a[i]=0
for i=0, a[i]≡a[0]=1
for i<0, a[i]=1 iff to the left of v on the distance exactly -i there is a vertex, otherwise a[i]=0
A simple understanding of this array is as follows. Stretch your graph and lay it along the coordinate axis so that each edge has the length equal to its weight, and that vertex v lies in the origin. Then a[i]=1 iff there is a vertex at coordinate i.
For your example and for vertex "b" chosen as v:
a--------b--c--d--e
--|--|--|--|--|--|--|--|--|-->
-4 -3 -2 -1 0 1 2 3 4
a: ... 0 1 0 0 1 1 1 1 0 ...
For another array, array b, we define the values in a symmetrical way with respect to origin, as if we have inverted the direction of the axis:
for i>0, b[i]=1 iff to the left of v on the distance exactly i there
is a vertex, otherwise b[i]=0
for i=0, b[i]≡b[0]=1
for i<0, b[i]=1 iff to the right of v on the distance exactly -i there is a vertex, otherwise b[i]=0
Now consider a third array c such that c[i]=a[i]*b[i], asterisk here stays for ordinary multiplication. Obviously c[i]=1 iff the path of length abs(i) to the left ends in a vertex, and the path of length abs(i) to the right ends in a vertex. So for i>0 each position in c that has c[i]=1 corresponds to the path you need. There are also negative positions (c[i]=1 with i<0), which just reflect the positive positions, and one more position where c[i]=1, namely position i=0.
Calculate the sum of all elements in c. This sum will be sum(c)=2P+1, where P is the total number of paths which you need with v being its center. So if you know sum(c), you can easily determine P.
Let us now consider more closely arrays a and b and how do they change when we change the vertex v. Let us denote v0 the leftmost vertex (the root of your tree) and a0 and b0 the corresponding a and b arrays for that vertex.
For arbitrary vertex v denote d=dist(v0,v). Then it is easy to see that for vertex v the arrays a and b are just arrays a0 and b0 shifted by d:
a[i]=a0[i+d]
b[i]=b0[i-d]
It is obvious if you remember the picture with the tree stretched along a coordinate axis.
Now let us consider one more array, S (one array for all vertices), and for each vertex v let us put the value of sum(c) into the S[d] element (d and c depend on v).
More precisely, let us define array S so that for each d
S[d] = sum_over_i(a0[i+d]*b0[i-d])
Once we know the S array, we can iterate over vertices and for each vertex v obtain its sum(c) simply as S[d] with d=dist(v,v0), because for each vertex v we have sum(c)=sum(a0[i+d]*b0[i-d]).
But the formula for S is very simple: S is just the convolution of the a0 and b0 sequences. (The formula does not exactly follow the definition, but is easy to modify to the exact definition form.)
So what we now need is given a0 and b0 (which we can calculate in O(L) time and space), calculate the S array. After this, we can iterate over S array and simply extract the numbers of paths from S[d]=2P+1.
Direct application of the formula above is O(L^2). However, the convolution of two sequences can be calculated in O(L log L) by applying the Fast Fourier transform algorithm. Moreover, you can apply a similar Number theoretic transform (don't know whether there is a better link) to work with integers only and avoid precision problems.
So the general outline of the algorithm becomes
calculate a0 and b0 // O(L)
calculate S = corrected_convolution(a0, b0) // O(L log L)
v0 = leftmost vertex (root)
for v in vertices:
d = dist(v0, v)
ans = ans + (S[d]-1)/2
(I call it corrected_convolution because S is not exactly a convolution, but a very similar object for which a similar algorithm can be applied. Moreover, you can even define S'[2*d]=S[d]=sum(a0[i+d]*b0[i-d])=sum(a0[i]*b0[i-2*d]), and then S' is the convolution proper.)
I would like to be able to take a STL file (triangulated surface mesh) and populate the mesh with points such that the density of points in constant. I am writing the program in Fortran.
So far I can read in binary STL files and store vertices and surface normals. Here is an example file which has been read in (2D view for simplicity).
My current algorithm fills each triangle using the following formula:
x = v1 + a(v2 - v1) + b(v3 - v1) (from here)
Where v1, v2, v3 are the vertices of the triangle and x is a arbitrary position within the triangle (or on the edges) . "a" and "b" vary between 0 and 1 and their sum is less than 1. They represent the distance along two of the edges (which start from the same vertex). The gap between the particles should be the same for each edge. Below is an example of the results I get:
The resulting particle density if nowhere near uniform. Do you have any idea how I can adapt my code such that the density will be constant from triangle to triangle? Relevant code below:
! Do for every triangle in the STL file
DO i = 1, nt
! The distance vector from the second point to the first
v12 = (/v(1,j+1)-v(1,j),v(2,j+1)-v(2,j),v(3,j+1)- v(3,j)/)
! The distance vector from the third point to the first
v13 = (/v(1,j+2)-v(1,j),v(2,j+2)-v(2,j),v(3,j+2)- v(3,j)/)
! The scalar distance from the second point to the first
dist_a = sqrt( v12(1)**2 + v12(2)**2 + v12(3)**2 )
! The scalar distance from the third point to the first
dist_b = sqrt( v13(1)**2 + v13(2)**2 + v13(3)**2 )
! The number of particles to be generated along the first edge vector
no_a = INT(dist_a / spacing)
! The number of particles to be generated along the second edge vector
no_b = INT(dist_b / spacing)
! For all the particles to be generated along the first edge
DO a = 1, no_a
! For all the particles to be generated along the second edge
DO b = 1, no_b
IF ((REAL(a)/no_a)+(REAL(b)/no_b)>1) EXIT
temp(1) = v(1,j) + (REAL(a)/no_a)*v12(1) + (REAL(b)/no_b)*v13(1)
temp(2) = v(2,j) + (REAL(a)/no_a)*v12(2) + (REAL(b)/no_b)*v13(2)
temp(3) = v(3,j) + (REAL(a)/no_a)*v12(3) + (REAL(b)/no_b)*v13(3)
k = k + 1
s_points(k, 1:3) = (/temp(1), temp(2), temp(3)/)
END DO
END DO
j = j + 3
END DO
The solution I went with was to split each triangle into two right angled triangles. This is done by projecting the vetex opposite the longest edge orthogonally onto the longest edge. This splits the trianlge into two smaller triangles each with a 90 degree angle. A detailed answer on how to do this can be found here. By generating points along both 90° bends, a uniform distribution of particles can be achieved.
This method needs to be adapted so that particles are not generated more than once along edges which are common to multiple triangles. I have not done this yet. See image below for results. This solution does not achieve an isotropic distribution but this is not a concern for my intended application.
(Thanks to Vladimir F for his comments and advice on norm2, I tried to implement his approach but was not competent enough to get it to work).
In the latest IEEE Xtreme Competition, a problem I've tried to solve is this,
Input Two points p1(x1,y1) , p2(x2,y2) you must find the length of shortest path from p1 to p2,
for example if p1(1,1) , p2(4,4) then the shortest path has lenght of 9 edges,
I did something like depth first search, it works great if the distance between the two point is small, and take long time for example for the points (1,1) & (10,10),
And there is a limit on the points the maximum point is (12,12).
my approach is to convert the above picture to an undirected graph with all weights to 1, and then find the shortest path.
here are my function that finds the shortest path:
int minCost;
vector<int> path;
multimap<int,int> Connections;
typedef multimap<int,int>::iterator mmit;
void shortestPath(int cs){
if(cs > minCost)
return;
if(path.back() == Target){
if(cs < minCost)
minCost = cs;
return;
}
pair<mmit,mmit> it = Connections.equal_range(path.back());
mmit mit = it.first;
for( ; mit != it.second ; ++mit){
if(isVisited(mit->second))
continue;
markVisited(mit->second);
path.push_back(mit->second);
shortestPath(cs+1);
markUnvisited(mit->second);
path.pop_back();
}
}
Is there any way faster than this ?? could i use dijkstra for this undirected graph ??
Using Dijkstra or any kind of graph-based search seems like total overkill here. At each vertex, you just need to choose the next vertex that brings you closer to your target.
So you start in the centre of (1,1). You need to choose the starting vertex. Obviously this is the one in the south-east.
From there, you have three choices: move west, move north-east or move south-east. This is in fact the choice you have at every second vertex. You choose the direction that brings you closer (ie, subtends smallest angle with your target).
In fact, you can represent all your vertex co-ordinates in a sort of cheaty way. Notice that they are all roughly half-way between the hexagon coordinates. So you could say the first vertex is at (1.5,1.33).
Your possible moves at the first co-ordinate are the directions:
west = (0, -0.67)
north-east = (-0.5, 0.33)
south-east = (0.5, 0.33)
Let's call that the odd-movement. Now, the even-movement you have these choices:
east = (0, 0.67)
north-west = (-0.5, -0.33)
south-west = (0.5, -0.33)
So all you have to do is, for each possible direction, test the new distance (as the crow flies -- ie pythagoras) to your target. Choose the new vertex that has the smallest distance of the three choices. Obviously you don't have to compute the actual distance -- distance squared is fine.
You can figure out the initial and final moves, I'm sure.
One final point, obviously I'm using double arithmetic which is imprecise. You can scale all your directions (and of course your hexagon co-ordinates) by 6 and use integers.