2

Suppose we have a graph like this:

      5               3
A ───────────► B ───────┐
│                       │
│                       │
│                       │
│                       ▼
└─────────────────────► C
           10

In this situation. Both B and C are added to the priority queue. When B is explored, C gets added to the queue again, because C is B's neighbor. So essentially, each Vertex is added in to the queue as many times as there are edges going into that vertex. So in the worst case scenario, the priority queue can have E number of items in the queue. Adding and removing items take logE cost. This multiplied by the standard BFS cost of O(V + E) should give us a total cost of O((V + E)logE) but in all textbooks and everywhere the cost is mentioned as O((V + E)logV) why is that?

Even here it says that O(logE) is the same as O(logV) and they claim the total cost is O((V + E)logV). Why is logE the same as logV?

Aditya
  • 1,240
  • 2
  • 14
  • 38
  • 1
    Is this because, in the worst case if the graph is a fully connected graph and for V vertices there are V(V-1) edges? [source](https://stackoverflow.com/questions/5058406/what-is-the-maximum-number-of-edges-in-a-directed-graph-with-n-nodes) So, logE = log(V(V-1)) = O(log(V^2)) = O(2log(V)) = O(log(V))? – Aditya Jan 14 '23 at 19:31
  • 1
    Yes. (With Fibonacci heaps you even get down to O(E + V log V).) – David Eisenstat Jan 14 '23 at 19:38
  • So if my reasoning is right, then the space complexity should be O(V^2) right? The maximum load of the queue would be when all the edges are present in the queue. But in all places the space complexity is listed as O(V) even when we use a priority queue for managing the frontier. Why is the space complexity O(V)? – Aditya Jan 14 '23 at 19:45
  • 1
    The space usage can be quadratic if each incoming arc has a separate entry in the priority queue. This is not necessary; all but one arc with the smallest key can be discarded, bringing the space usage down to O(V). Typically this is done by using the DecreaseKey operation on a priority queue that supports it. Fibonacci heaps have an especially cheap DecreaseKey, running in amortized constant time. – David Eisenstat Jan 14 '23 at 20:09
  • So essentially if I was implementing Dijkstra's algorithm in C++ and given the fact that std::priority_queue doesn't support decreasing the key. In that case I would have to create a separate entry for each incoming arc, then in that case the space complexity would be quadratic? Am I right? – Aditya Jan 14 '23 at 20:13
  • 1
    Yes, std::priority_queue is probably not the best choice for Dijkstra on a dense graph. – David Eisenstat Jan 14 '23 at 20:20
  • Thanks. I am just preparing for interviews. In a 45 min interview I will just stick with what I get by default in the std library. I don't want to attempt implementing Fibonacci heap in an already stressful situation. I don't think I will ever get the opportunity to implement Dijkstra's algorithm in real world anyways :) So it's cool. – Aditya Jan 14 '23 at 20:26
  • Oh yeah, don't try to implement Fibonacci :P. Every interviewer is different, but for me, using the standard library and explaining the trade-off that you're making would be the ideal response. – David Eisenstat Jan 14 '23 at 21:01
  • O(log E) is the same as O(log V), because E < V^2, so log(E) < 2log(V) – Matt Timmermans Jan 14 '23 at 21:21

0 Answers0