dijkstras-algorithm | shortest path algorithm in different languages | Learning library

1. Despite the test, this implementation of Dijkstra may put Ω(E) items in the priority queue. This will cost Ω(E log E) with every comparison-based priority queue.

2. Why not E log V? Well, assuming a connected, simple, nontrivial graph, we have Θ(E log V) = Θ(E log E) since log (V−1) ≤ log E < log V² = 2 log V.

3. The O(E + V log V)-time implementations of Dijkstra's algorithm depend on a(n amortized) constant-time DecreaseKey operation, avoiding multiple entries for an individual vertex. The implementation in this question will likely be faster in practice on sparse graphs, however.

The paper you link to does not seem to deal with the Traveling Salesman Problem, but with bipartite matchings:

Both versions of the problem can be solved by solving n,n=max(|A|,|B|), single-source many-targets shortest-path (SSMTSP) problems in a derived graph, see Section 4.

A free node refers to a node that is not matched with any other node in the bipartite graph. This is stated in section 4 of the linked paper (page label 87), footnote 5:

A node is free if no edge in M is incident to it.

M is defined as the matching that needs to be computed on the previous page.

This algorithm seems to only be useful for this matching problem, which requires that you run it multiple times. It's only an improvement across these multiple runs for bipartite matchings, it is not a standalone algorithm.

So, for lack of code, here's your sample codified with BGL:

Live On Coliru

My understanding is that once a node is processed, it no longer needs to be considered.

If you mean with "considered" that its distance along the path is calculated, then this is true, but also consider that comparing a distance with the best value so far is not significantly more complex than checking whether a neighbor was already visited. In either case (algorithm), a truly visited node (i.e. a node that has been popped from the heap) will never be pushed unto the heap again.

Let's look at a variant of the algorithm where (only) the concept of "visited" is used to determine whether a neighbor should be put on the heap. I intentionally have tried to limit code changes, so the differences can be highlighted better:

There are two obvious errors. Line 5 (1-based) should be badNumL equ $-badNum, and line 7 should be gcdL equ $-gcdiv. Once those are fixed, there are a whole slew of other errors and warnings, but it will get you past the original error.

This one is better for the social networks case, however it could be bent to include the synonym chains as well. The algorithm I have in mind is the Dinic's since it's augmenting paths are selected to be the shortest available paths. This will allow us to modify the algorithm to suit your case. Also note that we will be working with integer network flows.

Graph construction:

• source, sink
• for every person p, nodes p_s, p_e and a directed edge (p_s, p_e) with the capacity of one.¹
• for every edge (u,v) in your original graph a chain of edges (u_e, x₁), (x₁, x₂), ... (x_k, v_s) so that the number of the chain links equals the weight of the (u, v).² This is to make use of the fact that Dinic finds the shortest improvement to the current flow so this penalizes the longer chains from being used too early.
• For the person a you want to start with, change the capacity of (x_s, x_e) to the number of paths you wish to find.³
• Ad an edge with unlimited capacity from the source to x_s
• Merge your target person with the sink. (Or add the appropriate edges)

Run the Dinic's algorithm. The resulting flow will consist of the maximal number of disjunct paths. If you terminate the algorithm soon enough, these will likely be quite short since that is what the algorithm starts with. However since the network flow in the graph we constructed attempts to maximize the number of disjunct paths, it will start to prefer the longer ones if it improves the count. That is why you might want to limit the capacity of the first node's edge.

¹Bigger capacities won't work for this case because it would just increase the flow through the shortest path uniformly. However you can try to tweak some of the edges if you wish to allow at least few hubs or if your branching starts later.
²Note that if you have unweighted graph, then the edge (u_e, v_s) will be enough.
³Or infinity if you wish to find all of them. This would likely come with the cost of them no longer being reasonably short.