STL中的扩充/索引priority_queue

Question

I am using STL priority_queue as an data structure in my graph application. You can safely assume it like a advance version of Prim's spanning tree algorithm. With in the Algorithm I want to find a node in the priority queue (not just a minimum node) efficiently.[ this is needed because cost of node might get changed and need to be fixed in priority_queue] All i have to do is augment the priority_queue and index it based on my node key's also. I don't find any way this can be done in STL. Can anyone have better idea how to do it in STL?

Answer 1

The std::priority_queue<T> doesn't support efficient look-up of nodes: it uses a d-ary heap , typically with d == 2 . This representation doesn't keep nodes put. If you really want to use a std::priority_queue<T> with Prim's algorithm, the only way is to just add nodes with their current shortest distance and possibly add each node multiple times. This turns the size of the into O(E) instead of O(N) , though, ie, for graphs with many edges it will result in a much higher complexity.

You can use something like std::map<...> but that really suffers from pretty much the same problem: you can either locate the next node to extract efficiently or you can locate the nodes to update efficiently.

The "proper" approach is to use a node-based priority queue, eg, a Fibanocci-heap : Since the nodes stay put, you can get a handle from the heap when inserting a node and efficiently update the distance of a node through the handle. Access to the closest node is efficient using the few top nodes in the heap's set of trees. The overall performance of basic heap operations ( push() , top() , and pop() ) are slower for Fibonacci heaps than for d-ary heaps but the efficient update of individual nodes makes their use worthwhile. I seem to recall that Prim's algorithm actually required Fibonacci-heaps anyway to achieve the tight complexity bound.

I know that there is an implementation of Fibonacci-heaps at Boost . An efficient implementation of Fibonacci heaps isn't entirely trivial but they are more efficient than just being of theoretical interest.