# Bucket Priority Queues with large integers for $O(1)$ insert and extract~min?

I recently got into a discussion about Priority Queues when the requirements allow for "best effort" removal (i.e. the removed key may not always be THE very highest priority, but it is relatively close).

After thinking about it a bit I stated "I could probably make it $O(1)$ by using buckets" and approximating the minimum (to bucket size precision). I was politely told that I was wrong. Not taking no for an answer, I later went to Google and found the ample literature on the subject, which seemed to confirm I was wrong :-|

Note that the closely related question, Unique integer priority queue with both $O(1)$ insert and extract-min?, does not allow for approximation, so the answers don't apply to my question.

I was told the standard solution to this problem is to use a queue where keys are appended to the end in $O(1)$ and read from the head in $O(1)$ and which is then periodically sorted in $O(\log N)$ or whatever sorting algorithm you can find.

Assuming 64-bit integers as keys, and a precision of $\pm 127$ (a 56-bit bucket)... Can't you just hold the buckets in a sparse array (so as not to require $2^{56}$ words of memory)... problem solved?

• What do you mean by a "sparse array"? How do you plan to implement that? With a binary search tree or somesuch? Then it's not $O(1)$; it is $O(\log n)$.
– D.W.
Sep 30, 2017 at 1:25
• The sparse array itself would be hash or bucket-based, to provide O(1) access. Sep 30, 2017 at 5:46
• "Note that the closely related question, Unique integer priority queue with both O(1) insert and extract-min?, does not allow for approximation, so the answers don't apply to my question." -- if a method solves the problem exactly, it also solves them approximately.
– Raphael
Sep 30, 2017 at 5:50
• Hash tables do not provide worst-case O(1) access.
– Raphael
Sep 30, 2017 at 5:51
• It is averaged/amortized for hash is O(1). The exact solution is not O(1). Sep 30, 2017 at 7:23