Package org.jheaps.tree

Class StrictFibonacciHeap<K,V>

java.lang.Object
org.jheaps.tree.StrictFibonacciHeap<K,V>
Type Parameters:
K - the type of keys maintained by this heap
V - the type of values maintained by this heap
All Implemented Interfaces:
Serializable, AddressableHeap<K,V>, MergeableAddressableHeap<K,V>
public class StrictFibonacciHeap<K,V> extends Object implements MergeableAddressableHeap<K,V>, Serializable
Strict Fibonacci heaps. The heap is sorted according to the natural ordering of its keys, or by a Comparator provided at heap creation time, depending on which constructor is used.

A strict Fibonacci heap is a pointer-based heap described in detail in the following paper:

  • Gerth Stølting Brodal, George Lagogiannis, and Robert E. Tarjan, Strict Fibonacci Heaps, ACM Transactions on Algorithms 21(2), Article 15, 2025.
Ordinary Fibonacci heaps achieve their bounds only in the amortized sense; a single decreaseKey or meld may still be expensive. A strict Fibonacci heap matches those same bounds in the worst case, on a pointer machine, using linear space. Every node is either active (owned by a live heap) or passive (its subtree structure has been "forgotten" by a cheap meld); active nodes are further either free or fixed, each fixed node carrying a small integer loss. A heap keeps its active nodes partitioned into a constant number of groups (the "fix-list"), which lets four O(1) local transformations restore, after every operation, the invariants that keep the maximum rank, degree and total loss of the heap logarithmic in its size. Melding two heaps simply marks every active node of the smaller heap passive in O(1) time (a single flag flip shared by all its nodes), discarding the smaller heap's bookkeeping instead of merging it, which is the key simplification over earlier worst-case constant-time meldable heaps.

This implementation provides worst-case O(1) time cost for the operations insert, findMin, meld and decreaseKey, and worst-case O(log(n)) time cost for the operations deleteMin and delete.

All the above bounds, however, assume that the user does not perform cascading melds on heaps such as: 

 d.meld(e);
 c.meld(d);
 b.meld(c);
 a.meld(b);
The above scenario, although efficiently supported by using union-find with path compression, invalidates the claimed bounds. More precisely, insert, findMin, deleteMin and meld, when invoked directly on a live heap reference, always remain worst-case as stated above, no matter how many melds that heap has previously been the receiver of. Only AddressableHeap.Handle.decreaseKey(Object) and AddressableHeap.Handle.delete(), when invoked on a handle that was absorbed into another heap through one or more melds in which its own heap was the smaller side, pay an additional amortized (not worst-case) union-find lookup in order to locate the handle's current heap.

Note that the ordering maintained by a strict Fibonacci heap, like any heap, and whether or not an explicit comparator is provided, must be consistent with equals if this heap is to correctly implement the AddressableHeap interface. (See Comparable or Comparator for a precise definition of consistent with equals.) This is so because the AddressableHeap interface is defined in terms of the equals operation, but a strict Fibonacci heap performs all key comparisons using its compareTo (or compare) method, so two keys that are deemed equal by this method are, from the standpoint of this heap, equal. The behavior of a heap is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the AddressableHeap interface.

Note that this implementation is not synchronized. If multiple threads access a heap concurrently, and at least one of the threads modifies the heap structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements or changing the key of some element.) This is typically accomplished by synchronizing on some object that naturally encapsulates the heap.

Author:
Dimitrios Michail
See Also:

  • Constructor Details

    • StrictFibonacciHeap

      public StrictFibonacciHeap()
      Constructs a new, empty heap, using the natural ordering of its keys. All keys inserted into the heap must implement the Comparable interface. Furthermore, all such keys must be mutually comparable: k1.compareTo(k2) must not throw a ClassCastException for any keys k1 and k2 in the heap. If the user attempts to put a key into the heap that violates this constraint (for example, the user attempts to put a string key into a heap whose keys are integers), the insert(Object key) call will throw a ClassCastException.

    • StrictFibonacciHeap

      public StrictFibonacciHeap(Comparator<? super K> comparator)
      Constructs a new, empty heap, ordered according to the given comparator. All keys inserted into the heap must be mutually comparable by the given comparator: comparator.compare(k1, k2) must not throw a ClassCastException for any keys k1 and k2 in the heap. If the user attempts to put a key into the heap that violates this constraint, the insert(Object key) call will throw a ClassCastException.
      Parameters:
      comparator - the comparator that will be used to order this heap. If null, the natural ordering of the keys will be used.

  • Method Details