## Trivial clarification with the analysis of the Dijkstra Algorithm as dealt with in Keneth Rosen’s “Discrete Mathematics and its Application”

I was going through the text, “Discrete Mathematics and its Application” by Kenneth Rosen where I came across the analysis of the Dijkstra Algorithm and felt that the values at some places of the analysis are not quite appropriate. The main motive of my question is not the analysis of the Dijkstra Algorithm in general( a better version and more clearer version exists in the CLRS text) but my main motive is analysis of the algorithm acurately as far as the mathematics is concerned, considering the below algorithm as just an unknown algorithm whose analysis is required to be done. I just want to check my progress by the fact that whether the thing which I pointed out as being weird, is actually weird or not.

Lets move on to the question. Below is the algorithm in the text.

ALGORITHM: Dijkstra’s Algorithm.

``procedure Dijkstra(G: weighted connected simple graph, with all weights positive)        {G has vertices a = v[1], ... ,v[n] = z and weights w(v[j], v[j])      where w(v[j], v[j]) = ∞ if {v[i],v[j]) is not an edge in G}      for i: = 1 to n         L(v[i]) := ∞      L(a) := 0      S:=∅      {the labels are now initialized so that the label of a is 0 and all          other labels are ∞, and S is the empty set}       while z ∉ S          u := a vertex not in S with L(u) minimal          S:= S ∪ {u}          for all vertices v not in S              if L(u) + w(u, v) < L(v) then                  L(v) := L(u) + w(u, v)              {this adds a vertex to S with minimal label and updates the labels of vertices not in S}            return L(z)  {L(z) = length of a shortest path from a to z} ``

The following is the analysis which they used:

We can now estimate the computational complexity of Dijkstra’s algorithm (in terms of additions and comparisons). The algorithm uses no more than $$n − 1$$ iterations where $$n$$ is the number of vertices in the graph, because one vertex is added to the distinguished set at each iteration. We are done if we can estimate the number of operations used for each iteration. We can identify the vertex not in S in the $$k$$th iteration with the smallest label using no more than $$n − 1$$ comparisons. Then we use an addition and a comparison to update the label of each vertex not in S in the $$k$$th iteration . It follows that no more than $$2(n − 1)$$ operations are used at each iteration, because there are no more than $$n − 1$$ labels to update at each iteration.

The algorithm uses no more than $$n − 1$$ iterations where $$n$$ is the number of vertices in the graph, because one vertex is added to the distinguished set at each iteration., What I feel is that it shall be $$n$$ iterations and not $$n$$ as in the very first iteration the vertex $$a$$ is included in the set $$S$$ and the process continues till $$z$$ is inserted into the set $$S$$ and $$z$$ may be the last vertex in the ordering i.e.$$v_n$$.

The rest statements are fine I hope.

## Is there a Dijkstra like pathfinding with condition satisfication algorithm?

Say we have a place-transition digraph system. A transition can fire if all input places have marks. A transition fires by consuming items from input places and placing one into each output place. A number near the transition is a transition price. So, for example, we can get an image like this:

We want to find the cheapest path from `From` to `To`. So it is quite simple to see how one can modify Dijkstra to find a path in algorithm terms, yet in terms of formal theory in generalised case it does not look so simple and there can appear loops and loop step related conditions. So Is there a Dijkstra like pathfinding with condition satisfaction algorithm?

## Analysis of Dijkstra algorithm’s (Lazy) running time

I’m trying to figure out the running time for a Dijkstra algorithm. All the sources I have read say that the running time is O(E * log (E)) for a lazy implementation.

But when we do the math we get O(E * (Log(E)+E*Log(E))).

Since E isn’t a constant, I don’t see how someone could reduce this to O(E * log (E).

Are we analyzing the wrong or is it possible to reduce?

``        while (!minPQ.isEmpty()) { <=== O(E)             Node min = minPQ.poll(); <=== O(log(e)              for (Edge edge : graph.adj(min)) { <=== O(E)                 if (min.getId() == target.getId()) {                     // Source and Target = Same edge                     if (edgeTo.size() == 0) edgeTo.put(target, edge);                      return;                 }                  relax(edge, min, vehicle); <=== log(e) (because of add method on PQ)             }       } ``

## Node ordering at contraction hierarchy of biDirectional Dijkstra

I try to understand the node ordering at contraction hierarchy.

To me, ordering and contracting node looks impossible because when contracting a node, then it influence the other node. Therefore, it looks impossible to calculate the exact node order.

Let me explain the node ordering.

According to the some parameters such as edge difference, we can order the node and put the node at the prioriry queue.

After ordering, we extract the minimum priority node.

Before contracting the node, we should compare its priority with the recomputed priority of the head of the node in the priority queue, assuming the node is contracted.

It is because the contracting behavior influence the order of the nodes.

In this case, I have a question. Is it possible we cannot extract any node in the priority queue?

For example, in the queue, there are the nodes A, B, C, D, E in the order.

When we extract the node A, we found node B is actual minimum node.

Therefore, we put node A in the queue, again and extract B.

But after that, we recomputed the priority node A, we get to know A is the minimum.

Then we have to put node B.

I think it can go on and on. Therefore we cannot contract any node.

Is my think reasonable? And then how can we design the algorithm of node ordering?

## Dijkstra and A* Algorithms: Why is A* faster?

I am learning about Dijkstra’s Algorithm and the A* Algorithm and I have manually worked through the graph attached here, which is supposed (I think) to demonstrate that the A* Algorithm is faster than the Dijkstra one. The sequence in which I chose the nodes is indicated by the circled numbers. I can see that the process is fairly simple but there are plenty of possibilities for human error, so please bear with me.

My course book says that the A* will be quicker.

I can’t see why this is true. Have I worked through the graph incorrectly?

It seems to me that both methods require that all nodes must be visited so where is the increase in efficiency?

## Dijkstra same weight but different edges [closed]

I read about Djikstra’s algorithm and I want to be sure about two fundamental things, would appreciate if you could answer me mathematically so I can understand how words are translated to math so I can use it in other uses as well.

so here are my questions:

1. if we mark the shortest path Djikstra’s algorithm found in some network with $$n$$ stations in some topological construction: does it necessarily find the shortest path between each pair of vertices?
2. assume there’s at least an additional path, somewhere from $$s$$ to $$t$$, with same weight but with different edges (meaning both paths don’t have a common edge), how can we find this edge?

I don’t understand it well and I will really appreciate explanation so I can understand it better.

Watched videos, read materials online, and tried to concise what I am not sure about so I can request it here to deepen my understanding.

thank you for your time and assistance

## Dijkstra shortest path yields unintuitive results

Considering the following nodes with edge weights in red, Dijkstra’s shortest path algorithm seems to return incorrect results, at least by the definition of the steps on wikipedia. By those rules, the distance from `0` to `2` will be calculated by passing through `1` instead of `3`.

The final distances (from `0`) would come out to:

`0` -> 0

`1` -> 0.2

`2` -> 1000.2

`3` -> 0.5

The weights in this case are bi-directional but I don’t see a way for information of the connection between `2` and `3` to ever affect the final distance between `0` and `2`. Am I missing something about the limitations of this algorithm on this type of graph or are the steps listed incorrect?

## How can i modify Dijkstra algorithm for equal situation?

I have a question below

In Dijkstra’s Algorithm, if there is more than one possible shortest path from u to any vertex v, any one of the paths can be the output of the algorithms as a shortest path. Assume now that if that is the case for any vertex v, i.e.there are many paths of the same minimum weight, you want to find the path with minimum number of edges. If there are stil ties then they can now be broken arbitrarily. Describe how to modify Dijkstra’s Algorithm to solve this problem

## Dijkstra without decrease key

I was reading though this paper, which suggests using dijkstra without edge relaxation, but to rather to just insert new nodes, cf page 16 for the pseudo code. But to me the code looks wrong. I think the comparison should be

``k <= d[u] ``

and also the update of the d[u] in the next line seems redundant to me. I think the delete-min operation can never return a vertex with distance label k which is strictly less than d[u] since whenever a vertex distance pair is inserted into the priority queue the distance array d is updated. Am I correct in assuming that this is a mistake in the paper?

## How can I avoid re-computation of Dijkstra algorithm if I add or remove one edge from a graph?

I have a nested graph filtration and each step I have to find the shortest path between two nodes. At each step I just add one edge to the graph so the re-computation of the Dijkstra algorithm is extremely redundant. Is there any algorithm to circumvent this?