24. Design MinMax Queue
β GFG solution to Design MinMax Queue problem: implement a queue with O(1) min/max operations using monotonic deques. π
The problem can be found at the following link: π Question Link
π§© Problem Description
Design a SpecialQueue data structure that functions like a normal queue but with additional support for retrieving the minimum and maximum element efficiently.
The SpecialQueue must support the following operations:
enqueue(x): Insert an element x at the rear of the queue.
dequeue(): Remove the element from the front of the queue.
getFront(): Return the front element without removing.
getMin(): Return the minimum element in the queue in O(1) time.
getMax(): Return the maximum element in the queue in O(1) time.
The queries are represented in numeric form:
1 x: Call enqueue(x)2: Call dequeue()3: Call getFront()4: Call getMin()5: Call getMax()
π Examples
Example 1
Example 2
π Constraints
$1 \le \text{queries.size()} \le 10^5$
$0 \le \text{values in the queue} \le 10^9$
β
My Approach
The optimal approach uses Monotonic Deques alongside a regular queue to maintain minimum and maximum elements efficiently:
Monotonic Deque Technique
Main Queue: Use a standard queue to maintain FIFO order for normal queue operations.
Minimum Deque: Maintain a monotonic increasing deque where:
Front element is always the minimum in the current queue
Remove elements from back if they are greater than the new element
This ensures the deque is always sorted in increasing order
Maximum Deque: Maintain a monotonic decreasing deque where:
Front element is always the maximum in the current queue
Remove elements from back if they are smaller than the new element
This ensures the deque is always sorted in decreasing order
Enqueue Operation:
Add element to main queue
Remove larger elements from minimum deque's back and add current element
Remove smaller elements from maximum deque's back and add current element
Dequeue Operation:
Remove front element from main queue
If this element is at front of min deque, remove it
If this element is at front of max deque, remove it
Query Operations:
getFront(): Return front of main queue
getMin(): Return front of minimum deque
getMax(): Return front of maximum deque
π Time and Auxiliary Space Complexity
Expected Time Complexity: O(1) amortized for all operations. Each element is added and removed from deques at most once, making the amortized time complexity constant.
Expected Auxiliary Space Complexity: O(n), where n is the number of elements in the queue. We use additional space for the monotonic deques to track min/max elements.
π§βπ» Code (C++)
β‘ View Alternative Approaches with Code and Analysis
π 2οΈβ£ Stack-Based Approach
π‘ Algorithm Steps:
Use two stacks to simulate queue behavior (input and output stacks).
Maintain separate min/max stacks for each input/output stack.
Transfer elements between stacks when needed for dequeue operations.
Track min/max across both stacks during operations.
π Complexity Analysis:
Time: β±οΈ O(1) amortized - Each element transferred at most once
Auxiliary Space: πΎ O(n) - Multiple stacks for tracking
β
Why This Approach?
Pure stack-based implementation without deque
Amortized O(1) for all operations
Good for environments where deque is not available
π 3οΈβ£ Timestamped Monotonic Queue
π‘ Algorithm Steps:
Use timestamps to handle element removal correctly.
Maintain increasing deque for minimum with timestamps.
Maintain decreasing deque for maximum with timestamps.
Use timestamps to identify which elements to remove during dequeue.
π Complexity Analysis:
Time: β±οΈ O(1) amortized - Each element processed once
Auxiliary Space: πΎ O(n) - Timestamp tracking
β
Why This Approach?
Handles duplicate values correctly with timestamps
Maintains strict ordering for identical elements
Robust against edge cases with repeated values
π π Comparison of Approaches
π Approach
β±οΈ Time Complexity
πΎ Space Complexity
β Pros
β οΈ Cons
π·οΈ Deque-Based
π’ O(1) amortized
π’ O(n)
π Simple and efficient
π§ Requires deque support
π Stack-Based
π’ O(1) amortized
π‘ O(n)
π Pure stack implementation
πΎ Higher space overhead
π Timestamped
π’ O(1) amortized
π‘ O(n)
β Handles duplicates well
π§ Extra timestamp overhead
π Best Choice Recommendation
π― Scenario
ποΈ Recommended Approach
π₯ Performance Rating
π General use case
π₯ Deque-Based
β β β β β
π No deque available
π₯ Stack-Based
β β β β β
π― Many duplicates
π₯ Timestamped
β β β β β
β Code (Java)
π Code (Python)
π§ Contribution and Support
For discussions, questions, or doubts related to this solution, feel free to connect on LinkedIn: π¬ Any Questions?. Let's make this learning journey more collaborative!
β If you find this helpful, please give this repository a star! β
πVisitor Count
Last updated