The Logarithmic Funnel Heap: An Efficient Priority Queue For Extremely Large Sets

TL;DR

This paper introduces the Logarithmic Funnel Heap, an efficient indexed priority queue with near-logarithmic expected operation times suitable for handling extremely large data sets in computational tasks.

Contribution

It presents a novel heap data structure with expected $O( ext{log}^* n)$ and $O( ext{log} ext{log} n)$ operation times, improving efficiency for large-scale applications.

Findings

Insert, delete, decrease run in expected O(log* n) time.

Increase operation is conjectured to run in expected O(log log n) time.

Space and construction time are linear, O(n).

Abstract

For many data-processing applications, a comprehensive set of efficient operations for the management of priority values is required. Indexed priority queues are particularly promising to satisfy this requirement by design. In this work, we report the design and analysis of an efficient indexed priority queue with a comprehensive set of operations. In particular, $\mathtt{insert}$, $\mathtt{delete}$ and $\mathtt{decrease}$ all run in expected $O(\log^{*}{n})$ time, while $\mathtt{increase}$ is conjectured by means of Monte Carlo simulations to run in expected $O(\log\log{n})$ time. The space complexity as well as the time complexity for the construction of the empty heap data structure is $O(n)$. For certain massive computational problems, such as specific analyses of extremely large graphs and (chemical) simulations, this heap system may exhibit considerable utility.

Tables

Table 1. Table 1: Overview of heap system operations and associated time complexities on elements with unique immutable identifiers i ​ d 𝑖 𝑑 id and mutable, potentially degenerate priorities p 𝑝 p . The expression log ∗ ⁡ n superscript 𝑛 \log^{*}{n} denotes the iterated logarithm (see Section 2.3 for more details).

Name	Operation	Time Complexity	Section
$\mathrm{𝚖𝚊𝚔𝚎}\text{-}\mathrm{𝚑𝚎𝚊𝚙}(\lambda ,\text{n})$	Make empty ($\lambda$+1)-level heap for $n$ elements.	$O\left(n\right)$	3.1
$\mathrm{𝚏𝚒𝚗𝚍}\text{-}\mathrm{𝚖𝚊𝚡}\left(\right)$	Access element with highest priority.	$O\left(1\right)$	3.2
$\mathrm{𝚍𝚎𝚕𝚎𝚝𝚎}\text{-}\mathrm{𝚖𝚊𝚡}\left(\right)$	Delete element with the highest priority.	$O\left(\log n\right)$	3.3
$\mathrm{𝚒𝚗𝚜𝚎𝚛𝚝}(\mathrm{𝚒𝚍},𝚙)$	Insert element $id$ with priority $p$.	$O\left({\log }^{\ast }n\right)$ 222Expected running time.	3.4.1
$\mathrm{𝚍𝚎𝚕𝚎𝚝𝚎}\left(\mathrm{𝚒𝚍}\right)$	Delete the element $id$.	$O\left({\log }^{\ast }n\right)$ 22footnotemark: 2	3.4.2
$\mathrm{𝚍𝚎𝚌𝚛𝚎𝚊𝚜𝚎}(\mathrm{𝚒𝚍},{𝚙}^{\prime })$	Decrease priority from $p$ to $p^{\prime }$ of element $id$.	$O\left({\log }^{\ast }n\right)$ 22footnotemark: 2	3.4.3
$\mathrm{𝚒𝚗𝚌𝚛𝚎𝚊𝚜𝚎}(\mathrm{𝚒𝚍},{𝚙}^{\prime })$	Increase priority from $p$ to $p^{\prime }$ of element $id$.	$O\left(\log \log n\right)$ 22footnotemark: 2333Projected upper-bound of expected running time - determined using Monte Carlo simulations. See Section 3.5.	3.5

Equations

$${\log }^{\alpha \ast }n:=\{\begin{array}{ll}0& \text{if }n\le \alpha \\ 1+{\log }^{\alpha \ast }(\log n)& \text{if }n>\alpha \end{array}$$

$${\lambda }_{\alpha }\equiv {\log }^{\alpha \ast }n$$

$$k_{\ell }:=\frac{n_{\ell }}{\log n_{\ell }}=\frac{n_{\ell }}{n_{\ell -1}}=\frac{\stackrel{\lambda -\ell \text{ times}}{\overbrace{\log ...\log }}{n}_{\lambda }}{\underset{\lambda -\ell +1\text{ times}}{\underbrace{\log ...\log }}{n}_{\lambda }}$$

$$T_{\ell }=\{\begin{array}{ll}{c}_0& \text{if }\ell =0\\ k_{\ell }{T}_{\ell -1}+k_{\ell }+c_{\ell }& \text{if }0<\ell \le \lambda \end{array}$$

$$T_{\ell }=\{\begin{array}{ll}{c}_0& \text{if }\ell =0\\ T_{\ell -1}+\log k_{\ell }+c_{\ell }& \text{if }0<\ell \le \lambda \end{array}$$

$$T_{\ell }=\{\begin{array}{ll}{c}_0& \text{if }\ell =0\\ T_{\ell -1}+c_{\ell }& \text{if }0<\ell \le \lambda \end{array}$$

$$T_{\ell }=\{\begin{array}{ll}{c}_0& \text{if }\ell =0\\ T_{\ell -1}+\log \log n_{\ell }+c_{\ell }& \text{if }0<\ell \le \lambda \end{array}$$

$$S_{\ell }=O(n_{\lambda })+\{\begin{array}{ll}{c}_0& \text{if }\ell =0\\ k_{\ell }{S}_{\ell -1}+c_{\ell }& \text{if }0<\ell \le \lambda \end{array}$$

Full text

Introduction

A heap data structure maintains a specific partial ordering of a collection of comparable types. The heap is one of the most ubiquitously utilized data structures in computer science. Priority queues are employed in a broad range of important applications, from simulations [1, 2], to scheduling [3, 4], and graph analysis [5]. A broad survey into the variety of forays into heap research revealed a large number of ideas and approaches that have shaped the development of priority queues and beyond [6].

In 1964, Williams [7] was the first to introduce a sorting algorithm based on the notion of an array-based heap. An example of an efficient priority queue in practice is based on van Emde Boas Trees [8] and widely used in network routers. Various priority queues have been devised that exhibit optimal running times for common heap operations. Those ideas transformed the ability to analyze complex graph problems. Among them, the Pairing-Heap [9], the Fibonacci heap [10], * Brodal Queues* [11], and the Rank-Pairing Heap [12]. Another group of efficient data structures for shortest-path algorithms turn out to be so-called multi-level bucket heaps [13, 14]. For applications employing monotone sequences and involving shortest-path algorithms, especially efficient monotone priority queues have been designed [15, 16].

In this work, we present the design and analysis of an indexed priority queue, named the Logarithmic Funnel. This priority queue maintains uniquely identifiable elements that contain priority values in heap-order and supports comprehensive functionality for efficient modification of the priorities. Additionally, it also enables efficient deletion of elements from the priority queue. We will demonstrate runtime and space characteristics of this heap system in the realization of a max-heap, which besides the common heap operations, namely $\mathtt{insert,find\textrm{-}max,delete\textrm{-}max}$, also facilitates the specific heap operations, $\mathtt{increase,decrease}$ and $\mathtt{delete}$ on its elements $[id:p]$, where $id$ represents an immutable identifier and $p$,the priority, a comparable and mutable type. For a summary of the runtime behavior, see Table 1 below.

Beyond the present overview, this report contains three additional sections. Basic properties and structural composition of the Logarithmic Funnel are detailed in Section 2. The functional facilities supported by this heap system are analyzed and its associated computational complexities are established in Section 3. In Section 4, we then conclude with some remarks, allude to some open questions, and mention a few potential extensions to this heap system.

Structure and Composition of the Logarithmic Funnel $H_{\lambda}$

The Logarithmic Funnel is an indexed priority queue. It is a recursive and composite data type built from two families of specific composite heap types, namely the base heap type $H_{0}$ and the inductive heap types $H_{\ell}$ with $0<\ell\leq\lambda$. The recursive nature and data type composition of this heap system are graphically illustrated in Figure 1. A Logarithmic Funnel with $\lambda$ inductive levels is denoted as $H_{\lambda}$, and is constructed from multiple instances of all $\lambda$ distinct heap types $H_{\ell}$ where $\ell\in[1\mathrel{{.}\,{.}}\nobreak\lambda]$, and multiple instances of base heaps $H_{0}$.

The heap system contains a single global hash table, the location_table $\mathbb{T}$, to store a specific set of $[id:[heap-addresses]]$-bundle. The table $\mathbb{T}$ essentially acts as a routing table facilitating a unique path down the system to the particular base heap $H_{0}$ that stores the required element that is associated with the unique identifier $id$.

Base Heap Type $H_{0}$

Structurally, base heaps $H_{0}$ are a small composite data structures that in addition to core heap functionalities, also support naive operations for decrease and increase of the priority value of an element, as well as deletion of an element. Base heaps $H_{0}$ consist of two distinct data types, (i) a backpointer to its parent inductive heap, a heap of type $H_{1}$, and (ii) an array-based, implicit max-heap that maintains a very small set of constant-size elements of the form $id:p$, where $id$ is a unique and immutable identifier and $p$ is a mutable and comparable priority value.

The data elements of the heap system $H_{\lambda}$ are exclusively managed by $H_{0}$ heaps, i.e. all element operations occur only on the base-level. The inductive level functions of the heap system only serve to direct the requested action on the element to the particular $H_{0}$ base heap hosting the specific element.

See Section 2.3 and Figure 2 for more details on base heap sizes. An exciting recent results seemingly supporting this particular design choice was presented by Mankowitz, Michi, Zhernov et al.[17]. They discovered highly efficient, optimized algorithms to sort short sequences of elements. Benchmarks using these sort implementations in the LLVM C++ library [18] revealed improvements of up to 70% for sequences of a length of five for uint32, uint64 and float on specific architectures [17].

Inductive Heap Types $H_{\ell}$

The composition of the inductive heap types $H_{\ell}$ is being depicted in the bottom half of Fig. 1. Each heap of type $H_{\ell}$ consists of an array-based binary max-heap denoted as $\mathtt{\alpha}$ $\mathbb{M}$, a backpointer $\mathbb{B}$ to the metaheap of its parent heap, a $H_{\ell+1}$ heap, and a variable heap_max to keep track of the local max-priority element.

The elements of the metaheap of an inductive heap $H_{\ell}$ are pointers $\mathbb{P}$ to heaps of type $H_{\ell-1}$. The metaheap implicitly maintains in heap-order the max-priority elements of its $k_{\ell}$ bidirectionally linked heaps of type $H_{\ell-1}$. The bidirectionality of the heap linkage is required in order to compute in constant time the position in the metaheap where a heap-property violation may have occurred as the result of an element deletion or the modification of its priority value.

The Depth $\lambda_{\alpha}$ of the Heap System $H_{\lambda}$

The time and space computational complexities associated with the operations inscribed to this heap system are defined by its level depth $\lambda$, or equivalently the shortest number of steps from level $\lambda$ to the base which maintain all data elements. The quantity $\lambda$ is determined by employing a small variation to the standard definition of the iterated logarithm [19].

Definition 2.1** (The Generalized Iterated Logarithm).**

Let $\alpha\in\mathbb{R}^{+}_{1}$, then we define the generalized iterated logarithm as follows,

[TABLE]

This expression defines the number of times the logarithm must be iteratively applied before the result is less than or equal to a small predefined constant value, $\alpha$. Definition 2.1 is introduced as extension to the common iterated logarithm, where $\alpha=1$, and in order to guide the construction of sufficiently small base heaps $H_{0}$, and consequently to enforce associated base heap operations with expected constant time complexities.

For convenience, we denote the level depth $\lambda_{\alpha}$ of the Logarithmic Funnel using Definition 2.1 as follows,

Definition 2.2** (Level Depth of the Logarithmic Funnel).**

[TABLE]

Since the generalized iterated logarithm $\lambda_{\alpha}$ terminates strictly faster than the common iterated logarithm $\log^{*}n$ for all problem sizes where $n\leq 2^{65536}$ and $\alpha>1$, the level depth $\lambda_{\alpha>1}$ is less than that for the common iterated logarithm $\lambda_{1}$. In Figure 2, the expected base heap size $n_{0}$ is depicted as a function of the total heap size $n_{\lambda}$ and for $\lambda_{\alpha}$ with values for $\lambda\in[2\mathrel{{.}\,{.}}\nobreak 4]$. The graph is suggestive of the notion that for total heap sizes $n_{\lambda}$ up to and even more than $2^{420}$ elements, a 3-level heap system would enable robustly maintaining expected base heap sizes $n_{0}$ smaller than or around 4, for which very efficient and highly optimized sort algorithms do exist[17].

Heap Size Control

The heap system $H_{\lambda}$ is designed such that the number of elements maintained on vertically adjacent heap level changes logarithmically (see Definition 2.3). The size of a metaheap $k_{\ell}$ and the expected number of maintained elements $n_{\ell-1}=\log n_{\ell}$ for each of its bidirectionally linked children $H_{\ell-1}$ is being determined by the total number of elements $n_{\ell}$ maintained by a heap $H_{\ell}$. Thus, a $\lambda$-level heap system is defined such that at any level $\ell$ with $\ell\in[1\mathrel{{.}\,{.}}\nobreak\lambda]$, the elements are assumed to be distributed uniformly over all $k_{\ell}$ heaps of type $H_{\ell-1}$, and each with expected size $n_{\ell-1}$.

Formally, we define an implicit heap size control mechanism such that $\forall\ell\in[1\mathrel{{.}\,{.}}\nobreak\lambda]$, the size of a metaheap $k_{\ell}$, i.e. the number of its children, heaps of type $H_{\ell-1}$, is defined by the following relation,

Definition 2.3** (Implicit metaheap Size Control in a $H_{\lambda}$ System).**

[TABLE]

Asymptotic Analysis of Time and Space Complexity

In the following sections, we define and analyze the runtime characteristics of the recursively defined operations inscribed onto the Logarithmic Funnel, an iterated, indexed heap data structure containing elements $[id:p]$, where $id$ is a unique, immutable identifier and $p$ a potentially degenerate, mutable priority of the element. In particular, we will consider mechanisms facilitating the insertion and deletion of elements, priority update operations, such as increase and decrease. The classical operations for obtaining and deleting the element containing the largest priority are also considered. Furthermore, we will evaluate a recursive construction mechanism for the heap system, and its associated space complexity.

For the most part, we focus the analysis of all supported operations only on the part of the algorithms acting on the inductive heaps $H_{\ell}$ where $0<\ell\leq\lambda$. The operations on base heaps $H_{0}$ either mirror standard algorithms on array-based binary heaps or are trivial deviations of them. For details on the structure of base ($H_{0}$) and inductive ($H_{\ell}$) heap types, please refer to sections 2.1 and 2.2, respectively. Recall that all operations on the heap are defined recursively. Thus, the proof structure will follow the typically associated schema of setting up and solving a recurrence relation including a base case ($\ell=0$) and an inductive step ($0<\ell\leq\lambda$).

Make-Heap

In order to construct a Logarithmic Funnel $H_{\lambda}$ with $\lambda$ inductive levels and a base level ($\ell=0$), two distinct types of constructors are employed to generate empty heap instances $H_{\ell}(\ell\in[1\mathrel{{.}\,{.}}\nobreak\lambda])$ and $H_{0}$, respectively. Although recursively defined, these operations are different in nature from all other operations supported by the heap system because they are not acting on the system itself but actually creating it. Here, we will focus on and prove by induction Theorem 1 on the computational time complexity of the make-heap operation for inductive levels $H_{\ell}$ where $0<\ell\leq\lambda$, and described by Algorithm 1.

Theorem 1**.**

Let $H_{\lambda}$ be the Logarithmic Funnel constructed to maintain $n_{\lambda}$ elements444an increase by many orders of magnitude is feasible often for identical values of $\lambda$, i.e. with $\lambda$ levels of inductive heaps $H_{\ell}$ ($0<\ell\leq\lambda$), and let make-heap be the constructor system of the heap, then its associated time complexity described by Algorithm 1 is $T_{\lambda}=O(n_{\lambda})$.

We will proceed demonstrating that the recurrence relation describing the running time of the make-heap operation described in Algorithm 1 can be stated as follows,

[TABLE]

and whose associated asymptotic solution is $T_{\ell}=O(n_{\ell})$.

Proof.

The base level instance $H_{0}$ of the heap system is a simple class containing an empty vector of elements and a small collection of book-keeping variables. The construction thus requires only constant time.

On the uppermost level $\lambda$, of which there exists only a single instance, we instantiate a globally used hash-map, the location_table optimized to deal with very roughly $n_{\ell}$ elements. This operation requires expected constant time.

More generally, for heaps $H_{\ell}$ where $0<\ell\leq\lambda$, the make-heap operation is defined by Algorithm 1. On lines 1 and 2, we establish a back connection to the parent $H_{\ell+1}$ metaheap, and set initial values for $id$ and $priority$ of the local heap_max element. Both actions are constant time operations. In line 3, the metaheap for this $H_{\ell}$ instance with $k_{\ell}$ elements is created, taking $O(k_{\ell})=O(n_{\ell})$ time. Here you may recall definition 2.3, $k_{\ell}=n_{\ell}/\log{n_{\ell}}$. Consecutively, in lines 4 and 5, the $k_{\ell}$ child $H_{\ell-1}$ heaps are created and connected to the $H_{\ell}$ metaheap elements. These $k_{\ell}$ make-heap operations take $O(k_{\ell}T_{\ell-1})$ time. Finally, the address of the created $H_{\ell}$ instance is returned to its parent in a constant time operation. In summary, we can assert the respective recurrence relation for an $H_{\ell}$ heap to be $T_{\ell}=k_{\ell}T_{\ell-1}+k_{\ell}$. Thus, the recurrence relation of the entire make-heap constructor system is defined by Eq. 3.1, and which thus for a Logarithmic Funnel $H_{\lambda}$ has the asymptotic solution $T_{\lambda}=O(n_{\lambda})$. ∎

Find-Max

The functionality $\mathtt{find\textrm{-}max()}$ is a part of the core set of heap operations, and by far the simplest operation supported by the Logarithmic Funnel. Below we describe its algorithm and determine its time complexity.

Theorem 2**.**

Let $n_{\lambda}$ be the total number of elements maintained by the Logarithmic Funnel $H_{\lambda}$, then the runtime complexity of the operation $\mathtt{find\textrm{-}max()}$ described by Algorithm 2 is $O(1)$.

Proof.

The base case is trivially true. Any base heap $H_{0}$, an array-based binary heap, stores the maximum priority element in the first position and is thus retrievable in $O(1)$ time. For any heap type $H_{\ell}$, the Algorithm 2 simply returns the value of the variable heap_max. Thus, the time complexity of the operation on any level $\ell$ with $0<\ell\leq\lambda$ can be formulated using a first-order recurrence relation with constant coefficients exhibiting the solution $T_{\lambda}=O(1)$. ∎

Delete-Max

The operation $\mathtt{delete\textrm{-}max}$ is also part of the core functionality that is supported by every heap system. We will describe an algorithm for this operation in the Logarithmic Funnel, analyze it and prove the following theorem:

Theorem 3**.**

Let $n_{\lambda}$ be the total number of elements maintained by the Logarithmic Funnel $H_{\lambda}$, and let $\mathtt{delete\textrm{-}max}$ be the supported operation on the heap system described by Algorithm 3, then its associated time complexity is $T_{\lambda}=O(\log{n_{\lambda}})$.

We will proceed verifying the correctness of the following recurrence relation,

[TABLE]

and whose associated asymptotic solution is $T_{\lambda}=O(\log{n_{\lambda}})$.

Proof.

On the base heap level ($\ell=0$), $\mathtt{delete\textrm{-}max}$ is replicating the classical operation of an implicit array-based binary heap, i.e. it restores heap-order in $O(\log n_{0})$ time, and in addition removes the unique identifier and its associated values from the location_table in expected constant time. Since the base heap size $n_{0}$ is defined to be a roughly constant $\delta$, the operation requires expected constant time.

On level $\ell$ where $0<\ell\leq\lambda$, lines 1 and 4 are constant time operations. On line 2, we refer work to the $H_{\ell-1}$ heap that lies on the iterated route down towards the particular base heap $H_{0}$ that currently contains the global max-priority element, and thus incurs $T_{\ell-1}$ time. On line 3, a downward-directed heap-order restoration of the metaheap on level $\ell$ is required as result of the heap-order violation induced by the max-priority element. This work requires $O(\log k_{\ell})$ = $O(\log n_{\ell})$ time. Finally, the work $T_{\ell}$ of $\mathtt{delete\textrm{-}max}$ on any level $\ell$ may be summarized by $T_{\ell-1}+\log k_{\ell}+c_{\ell}$, and consequently the runtime complexity in a Logarithmic Funnel $H_{\lambda}$ with $n_{\lambda}$ elements, is thus expected $O(\log{n_{\lambda}})$. ∎

Insert-Delete-Decrease Functionality

The operations insert, delete and decrease recursively defined operation on the Logarithmic Funnel $H_{\lambda}$ exhibit identical runtime complexities, namely $O(\log^{*}n_{\lambda})$ time, and metaheap update probabilities $p=1/n_{\ell-1}$. They may thus belong to the same category of functions, and are discussed together in the present section.

For Algorithms 4, 5 and 6, described in Sections 3.4.1, 3.4.2, 3.4.3 respectively, we show the correctness of the following recursion relation,

[TABLE]

and whose associated asymptotic solution is $T_{\lambda}=O(\lambda)\leq O(\log^{*}n_{\lambda})$.

Theorem 4**.**

Let $n_{\lambda}$ be the total number of elements maintained by the Logarithmic Funnel $H_{\lambda}$. The runtime complexity of the operations $\mathtt{insert}$, $\mathtt{delete}$, and $\mathtt{decrease}$ described by Algorithms 4, 5 and 6 is expected $O(\lambda)\leq O(\log^{*}n_{\lambda})$ time.

Insert

Proof.

From section 2.1, we know the structural setup of a base heap $H_{0}$. Briefly, on the base heap level ($\ell=0$), insert is essentially replicating the action of an implicit array-based binary heap, i.e. it inserts an element by retaining heap-order in $O(\log n_{0})$ time. Again, as with the previously described operations above, the base heap size $n_{0}$ is defined to be roughly a small constant $\delta$, and thus the base heap operation may be considered requiring expected constant time.

For inductive heaps $H_{\ell}$, i.e. where $0<\ell\leq\lambda$, the insert(id, p) operation is defined by Algorithm 4 as follows. On line 1, a random $H_{\ell-1}$ heap is selected uniformly via the metaheap to distribute insertions across the metaheap accordingly. Then, on line 2, it is established in constant time whether the heap-property in the metaheap is going to be violated as a result of the element insertion. On line 3, we fill the location_table of the heap $H_{\ell}$ with required element location information. All three operations require expected constant time. Next, on line 4, we transfer the element insertion action to the corresponding insert functionality on level $\ell-1$, consequently incurring a cost of $T_{\ell-1}$. Since the expected size of the $H_{\ell-1}$ heap that was earmarked for element insertion is $O(n_{\ell-1})=O(\log n_{\ell})$, and thus the associated update probability $p_{update}$ of a uniformly random priority being larger than the local max is of reciprocal complexity, in particular, $\frac{1}{n_{\ell-1}}=\frac{1}{\log n_{\ell}}$, the associated probability of requiring a metaheap update-operation with associated cost $O(\log k_{\ell})=O(\log n_{\ell})$ is thus amortized cost of $O(1)$.

In summary, the work on any level $\ell$ may be summarized by $T_{\ell-1}+c_{\ell}$, and thus the recurrence relation of the insert operation is described by 3.3, and the associated time complexity in a Logarithmic Funnel $H_{\lambda}$ with $n_{\lambda}$ elements, is thus expected $O(\lambda)$, i.e. $O(\log^{*}n_{\lambda})$ time. ∎

Delete

Proof.

Recall from Section 2.1 that the base case of this induction is true. Also at the base level, the unique identifier $id$ and all associated values in the location_table are removed in expected constant time. Thus, we continue by exploring the situation for inductive heaps, $H_{\ell}$ ($0<\ell\leq\lambda$), and where the $\mathtt{delete}$ operation is defined by Algorithm 5.

On level $\ell$, using the location-table, we first identify the $H_{\ell-1}$ heap that is maintaining the element with identifier $id$ on level $\ell-1$. Then we proceed to check in $O(1)$ time whether the current max-priority element of the identified $H_{\ell-1}$ heap is the target for deletion. If this is not the case, we merely invoke the level $\ell-1$ instance of the $\mathtt{delete}$ operation, and are done. Otherwise (line 5), we also need to restore the heap property in the level $\ell$ metaheap from the point of deletion since the operation potentially induced a violation of the heap order. Since the $H_{\ell-1}$ heap is of expected size $O(n_{\ell-1})$, and any deletion is assumed to be uniformly randomly distributed, this case occurs with probability $1/n_{\ell-1}$, and requires $O(\log k_{\ell})=O(\log n_{\ell})=O(n_{\ell-1})$ time. The amortized cost of this branch is then expected constant time. The total aggregated operational cost for $\mathtt{delete}$ on level $\ell$, is thus the sum of constant time work performed on level $\ell$, and a single operation referred to level $\ell-1$. As a result and including the constant time base case, the total cost of $\mathtt{delete}$ can be expressed by the recurrence relation in Eq. 3.3. The total operational cost of $\mathtt{delete}$ may consequently be stated as expected $O(\lambda)$ = $O(\log^{*}n_{\lambda})$ time. ∎

Decrease

Proof.

Using the properties of base heaps described in Section 2.1, the base case is true. Thus, we continue by exploring the situation for inductive heaps, $H_{\ell}$ ($0<\ell\leq\lambda$), and where the $\mathtt{decrease(id,p^{\prime})}$ operation is defined by Algorithm 6.

On level $\ell$, using the location-table and the unique identifier $id$, we first determine the particular $H_{\ell-1}$ heap that is maintaining the element on level $\ell-1$. Then we proceed to check in $O(1)$ time whether the current max-priority element of the identified $H_{\ell-1}$ heap is the target of the $\mathtt{decrease}$ operation. If this is not the case, we merely invoke the level $\ell-1$ instance of $\mathtt{decrease}$ on the identified $H_{\ell-1}$ heap, and are done. Otherwise (line 5), we also need to restore the heap property in the level $\ell$ metaheap from the point of change. Since the $H_{\ell-1}$ heap is of expected size $O(n_{\ell-1})$, and any priority decrease is assumed to be uniformly randomly distributed, this case occurs with probability $\frac{1}{n_{\ell-1}}$, and requires $O(\log k_{\ell})=O(\log n_{\ell})$ time, which is equivalent to an amortized cost for this branch of $O(1)$ time. Thus, the aggregated operational cost for $\mathtt{decrease}$ on level $\ell$, is the sum of expected constant time work performed on level $\ell$, and a single operation referred to level $\ell-1$. Finally, the total cost of the operation in a Logarithmic Funnel $H_{\lambda}$ can be summarized by the recurrence relation, Eq. 3.3 and whose operational cost may be stated as expected $O(\lambda)$, i.e. $O(\log^{*}n_{\lambda})$ time. ∎

Increase

The heap operations, $\mathtt{increase}$, together with $\mathtt{decrease}$, and $\mathtt{delete}$ constitute the set of operations of the heap system that facilitate the mutability of priority values in elements. All operations rely on a global hash table, the location_table, to retrieve the address of the particular $H_{\ell-1}$ heap that is en route to the element’s base heap, whereby the table lookup requires expected constant time. Recall that elements only exist in base heaps, and that is where they are being modified.

For the operation $\mathtt{increase}$, that is being discussed in this section, the analysis is not fully completed yet. Specifically, a derivation for the expression of the probability of requiring a metaheap update, $p_{update}$ (line 4 in Algorithm 7), after the priority of a specific element has been increased is still outstanding. To fill this gap in the analysis, and to at least proceed with an estimate of this probability, $\hat{p}_{update}$, Monte Carlo simulations on an accessible range of heap sizes have been performed (Figure 3).

Conjecture 5**.**

Let $n_{\lambda}$ be the total number of elements maintained by the Logarithmic Funnel $H_{\lambda}$. The running time of the operation $\mathtt{increase}$ described by Algorithm 7 is expected $O(\log\log n_{\lambda})$ time.

We proceed by conjecturing the correctness of the following recurrence relation,

[TABLE]

and whose associated asymptotic solution is $T_{\lambda}=O(\log\log n_{\lambda})$.

Proof.

Recall from Section 2.1 that the base case of this induction is true. Thus, we continue by exploring the situation for inductive heaps, $H_{\ell}$ ($\ell\in[1\mathrel{{.}\,{.}}\nobreak\lambda]$), and where the $\mathtt{increase}(id,p)$ operation is defined by Algorithm 7.

On level $\ell$, and using the location_table, the $H_{\ell-1}$ heap that is maintaining the element with identifier $id$ on level $\ell-1$ is being identified via an expected constant time cost lookup. We proceed to check in $O(1)$ time whether the new priority value p for element id would become the new heap_max element for its $H_{\ell-1}$ heap. If this was not the case, we simply invoke the level $\ell-1$ operation of $\mathtt{increase}$ on the identified $H_{\ell-1}$ heap, and are done. Otherwise (lines 5 $\&$ 6), since the $H_{\ell-1}$ heap received a new max priority which is now potentially violating the heap order within the level $\ell$ metaheap, we also need to restore the heap-property from the position of change up to its root. This update occurs with probability $p_{update}$, for which the estimate $\hat{p}_{update}$ on level $\ell$ based on Monte Carlo simulations appears asymptotically weakly upper-bounded by the function $g(n)=\frac{\log\log n}{\log n}$ (see Figure 3). The simulations are only a guide for future work and in order to get a sense of the current expected runtime of the operation without actually deriving an analytical expression. A metaheap update operation on line 5 requires $O(\log k_{\ell})$ time, which is equivalent to an amortized cost for this branch of $O(\log\log n_{\ell})$ time.

Thus, the aggregated operational cost for $\mathtt{increase}(id,p^{\prime})$ on level $\ell$, is the sum of expected constant work performed on level $\ell$, a single operation referred to level $\ell-1$, and the amortized cost for the metaheap update branch, i.e. $O(\log\log n_{\ell})$. As a result, the cost of $\mathtt{increase}$ on level $\ell$ can be expressed by the recurrence relation, $T_{\ell}=T_{\ell-1}+O(\log\log n_{\ell})+c_{1}$ as stated in Eq. 3.4. Thus, upon inclusion of the constant time base case and asserting that $\lambda\geq 2$ for virtually any anticipated use case of this heap data structure, we obtain a computational cost in a Logarithmic Funnel $H_{\lambda}$ for this operation of expected $O(\log\log n_{\lambda})$ time. ∎

Space Complexity

In the present section, we will analyze the space requirements of the Logarithmic Funnel $H_{\lambda}$, and arrive at the following theorem:

Theorem 6**.**

Let $n_{\lambda}$ be the number of constant-size elements managed by a Logarithmic Funnel $H_{\lambda}$, then the space complexity of the data structure $S_{\lambda}$ is $O(n_{\lambda})$.

We proceed by verifying the correctness of the following recurrence relation,

[TABLE]

and whose associated asymptotic solution is $S_{\lambda}=O(n_{\lambda})$.

Proof.

Firstly, on the uppermost level $\lambda$, there is a single global location_table requiring $O(n_{\lambda})$ space. Managed elements in the heap system require at least two constant-size data components, namely an identifier id and a comparable priority p. Thus, in addition to a simple constant-size data type to anchor back to its respective parent $H_{1}$ heap, a base-heap $H_{0}$ contains an array of expected $O(n_{0})$, i.e. constant space.

An inductive heap $H_{\ell}$ contains an array, the metaheap, of expected $O(k_{\ell})$ size, where each of the elements are linked to an $H_{\ell-1}$ heap of size $S_{\ell-1}$. Furthermore, each $H_{\ell}$ heap also contains two constant-size variables for bookkeeping and to anchor back to its parent $H_{\ell+1}$ heap. Aggregation of all partial space requirements leads to a total cost function for an inductive heap $H_{\ell}$, that may be stated as $S_{\ell}=k_{\ell}\>S_{\ell-1}+c_{\ell}$. Thus, for an entire heap system $H_{\lambda}$, we establish the total space cost to be correctly represented by the recurrence relation 3.5. The total space complexity $S_{\lambda}$ of a Logarithmic Funnel $H_{\lambda}$ may therefore be stated as $O(n_{\lambda})$. ∎

Conclusion

The design and analysis of an efficient indexed priority queue with a comprehensive set of operations for priority value management is presented. We show the data structure to exhibit expected $O(\log^{*}{n})$ running times for the operations $\mathtt{insert,delete}$ and $\mathtt{decrease}$, while the expected running time of the $\mathtt{increase}$ operation is stipulated to be weakly upper-bound by a function $h(n)=\log\log{n}$. The time complexity of the heap construction operation as well as the space complexity are demonstrated to be $O(n)$. For $\mathtt{find\textrm{-}max}$ and $\mathtt{delete\textrm{-}max}$, the standard running time complexities of $O(1)$ and $O(\log n)$ are established, respectively.

The practicality, robustness and flexibility of the presented data structure are yet to be explored. Despite its appealing computational complexity characteristics, it may well be too involved compared to lean implementations of other highly efficient heap systems in order to be reasonably competitive or useful. However, the outlined setup may have its own distinct benefits for a particular subset of massive graph and/or physical sciences problems if efficient implementations of the data structure can be realized, or necessary improvements can be found. On that note, an index-based as opposed to a pointer-based implementation, especially using contiguous storage for the current destinations of the pointers in the metaheap, will very likely exhibit substantially fewer cache misses, and thus proportionally correspond to lower constant factors in the running time characteristic. Thus, it is conceivable that interesting or other useful applications do exist for which this heap system shows great or potentially optimal utility with respect to other heap data structures in certain domains of interest.

Finally, with respect to future work on the Logarithmic Funnel, establishment of the actual running time of $\mathtt{increase}$ is an outstanding challenge. It is considered interesting to elucidate the concurrency potential of the data structure, as well as the exploration of avenues to create an approximately correct heap system albeit with strict error guarantees in turn for significantly increased speed on a typical sequence of operations.