Fibonacci heap

In computer science, a Fibonacci heap is a heap data structure consisting of a forest of trees. It has a better amortized running time than a binomial heap. Fibonacci heaps were developed by Michael L. Fredman and Robert E. Tarjan in 1984 and first published in a scientific journal in 1987. The name of Fibonacci heap comes from Fibonacci numbers which are used in the running time analysis.

Operations insert, find minimum, decrease key, and merge (union) work in constant amortized time. Operations delete and delete minimum work in O(log "n") amortized time. This means that, starting from an empty data structure, any sequence of "a" operations from the first group and "b" operations from the second group would take "O"("a" + "b" log "n") time. In a binomial heap such a sequence of operations would take "O"(("a" + "b")log ("n")) time. A Fibonacci heap is thus better than a binomial heap when "b" is asymptotically smaller than "a".

The use of Fibonacci heaps improves the asymptotic running time of Dijkstra's algorithm for computing shortest paths in a graph and Prim's algorithm for computing a minimum spanning tree of a graph.

Structure of a Fibonacci heap

A Fibonacci heap is a collection of trees satisfying the minimum-heap property, that is, the key of a child is always greater than or equal to the key of the parent. This implies that the minimum key is always at the root of one of the trees. Compared with binomial heaps, the structure of a Fibonacci heap is more flexible. The trees do not have a prescribed shape and in the extreme case the heap can have every element in a separate tree or a single tree of depth "n". This flexibility allows some operations to be executed in a "lazy" manner, postponing the work for later operations. For example merging heaps is done simply by concatenating the two lists of trees, and operation "decrease key" sometimes cuts a node from its parent and forms a new tree.

However at some point some order needs to be introduced to the heap to achieve the desired running time. In particular, degrees of nodes (here degree means the number of children) are kept quite low: every node has degree at most "O"(log "n") and the size of a subtree rooted in a node of degree "k" is at least "F"_{"k" + 2}, where "F"_"k" is "k"th Fibonacci number. This is achieved by the rule that we can cut at most one child of each non-root node. When a second child is cut, the node itself needs to be cut from its parent and becomes a root of a new tree. The number of trees is decreased in the operation "delete minimum", where trees are linked together.

As a result of a relaxed structure, some operations can take a long time while others are done very quickly. In the amortized running time analysis we pretend that very fast operations take a little bit longer than they actually do. This additional time is then later subtracted from the actual running time of slow operations. The amount of time saved for later use is measured at any given moment by a potential function. The potential of a Fibonacci heap is given by

:Potential = "t" + 2"m"

where "t" is the number of trees in the Fibonacci heap, and "m" is the number of marked nodes. A node is marked if at least one of its children was cut since this node was made a child of another node (all roots are unmarked).

Thus, the root of each tree in a heap has one unit of time stored. This unit of time can be used later to link this tree with another tree at amortized time 0. Also, each marked node has two units of time stored. One can be used to cut the node from its parent. If this happens, the node becomes a root and the second unit of time will remain stored in it as in any other root.

Implementation of operations

To allow fast deletion and concatenation, the roots of all trees are linked using a circular, doubly linked list. The children of each node are also linked using such a list. For each node, we maintain its number of children and whether the node is marked. Moreover we maintain a pointer to the root containing the minimum key.

Operation find minimum is now trivial because we keep the pointer to the node containing it. It does not change the potential of the heap, therefore both actual and amortized cost is constant. As mentioned above, merge is implemented simply by concatenating the lists of tree roots of the two heaps. This can be done in constant time and the potential does not change, leading again to constant amortized time. Operation insert works by creating a new heap with one element and doing merge. This takes constant time, and the potential increases by one, because the number of trees increases. The amortized cost is thus still constant.

Operation extract minimum (same as "delete minimum") operates in three phases. First we take the root containing the minimum element and remove it. Its children will become roots of new trees. If the number of children was "d", it takes time "O"("d") to process all new roots and the potential increases by "d"-1. Therefore the amortized running time of this phase is "O"("d") = "O"(log "n").

However to complete the extract minimum operation, we need to update the pointer to the root with minimum key. Unfortunately there may be up to "n" roots we need to check. In the second phase we therefore decrease the number of roots by successively linking together roots of the same degree. When two roots "u" and "v" have the same degree, we make one of them a child of the other so that the one with smaller key remains the root. Its degree will increase by one. This is repeated until every root has a different degree. To find trees of the same degree efficiently we use an array of length "O"(log "n") in which we keep a pointer to one root of each degree. When a second root is found of the same degree, the two are linked and the array is updated. The actual running time is "O"(log "n" + "m") where "m" is the number of roots at the beginning of the second phase. At the end we will have at most "O"(log "n") roots (because each has a different degree). Therefore the potential decreases by at least "m"-"O"(log "n") and the amortized running time is "O"(log "n").

In the third phase we check each of the remaining roots and find the minimum. This takes "O"(log "n") time and the potential does not change. The overall amortized running time of extract minimum is therefore "O"(log "n").

Operation decrease key will take the node, decrease the key and if the heap property becomes violated (the new key is smaller than the key of the parent), the node is cut from its parent. If the parent is not a root, it is marked. If it has been marked already, it is cut as well and its parent is marked. We continue upwards until we either reach the root or unmarked vertex. In the process we create some number, say "k", new trees. Each of these new trees except possibly the first one was marked originally but as a root it will become unmarked. One node can become marked. Therefore the potential decreases by at least "k" − 2. The actual time to perform the cutting was "O"("k"), therefore the amortized running time is constant.

Finally, operation delete can be implemented simply by decreasing the key of the element to be deleted to minus infinity, thus turning it into the minimum of the whole heap. Then we call extract minimum to remove it. The amortized running time of this operation is "O"(log "n").

Worst case

Although the total running time of a sequence of operations starting with an empty structure is bounded by the bounds given above, some (very few) operations in the sequence can take very long to complete (in particular decrease key, delete and delete minimum have linear running time in the worst case). For this reason Fibonacci heaps and other amortized data structures may not be appropriate for real-time systems.

ummary of running times

(*)Amortized time

References

* Fredman M. L. & Tarjan R. E. (1987). [http://doi.acm.org/10.1145/28869.28874 Fibonacci heaps and their uses in improved network optimization algorithms.] "Journal of the ACM" 34(3), 596-615.
* Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. "Introduction to Algorithms", Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7. Chapter 20: Fibonacci Heaps, pp.476–497.

External links

* [http://www.cs.yorku.ca/~aaw/Jason/FibonacciHeapAnimation.html Java applet simulation of a Fibonacci heap]
* [http://resnet.uoregon.edu/~gurney_j/jmpc/fib.html C implemention of Fibonacci heap]
* [http://www.cs.princeton.edu/~wayne/cs423/fibonacci/FibonacciHeapAlgorithm.html Pseudocode of the Fibonacci heap algorithm]