RLE Iterator - Practice Coding Problems

RLE Iterator - Problem

Run-Length Encoding (RLE) Iterator

Imagine you have a compressed sequence of numbers where instead of storing repeated values multiple times, you store pairs of [count, value]. This is called Run-Length Encoding!

For example, the sequence [8,8,8,5,5] can be compressed to [3,8,2,5] meaning "3 times the number 8, then 2 times the number 5".

Your Mission: Design an iterator that can efficiently traverse through this compressed format without expanding the entire sequence into memory.

Key Operations:
• RLEIterator(encoded) - Initialize with a run-length encoded array
• next(n) - Skip the next n elements and return the last element consumed. If there aren't enough elements, return -1

Think of it like fast-forwarding through a compressed video - you need to jump ahead efficiently without decompressing everything!

Input & Output

example_1.py — Basic Usage

$ Input: RLEIterator([3,8,0,9,2,5]) next(2), next(1), next(1), next(2)

› Output: 8, 8, 5, -1

💡 Note: The sequence is [8,8,8,5,5]. next(2) consumes first 2 elements, returns 8. next(1) consumes 1 more (the last 8), returns 8. next(1) consumes first 5, returns 5. next(2) tries to consume 2 more but only 1 element left, returns -1.

example_2.py — Zero Counts

$ Input: RLEIterator([2,3,0,5,1,7]) next(1), next(2)

› Output: 3, 7

💡 Note: Sequence is [3,3,7]. The (0,5) pair contributes no elements. next(1) returns 3, next(2) consumes the remaining 3 and the 7, returning 7.

example_3.py — Large Skip

$ Input: RLEIterator([1000000,1,1,2]) next(999999), next(2)

› Output: 1, 2

💡 Note: First pair has 1 million 1's. next(999999) consumes 999,999 ones, returns 1. next(2) consumes the last 1 and the single 2, returns 2.

Constraints

1 ≤ encoding.length ≤ 1000
encoding.length is even
0 ≤ encoding[i] ≤ 10⁹
1 ≤ n ≤ 10⁹
At most 1000 calls will be made to next

Visualization

Tap to expand

Understanding the Visualization

Compressed Storage

Store data as [count, value] pairs like video frames with durations

Position Tracking

Maintain pointers to current segment and consumption within that segment

Efficient Skipping

Jump through segments consuming elements until request is satisfied

Key Takeaway

🎯 Key Insight: Instead of expanding compressed data, maintain smart pointers to navigate efficiently through the original compressed format, preserving both memory and the benefits of compression.

Asked in

G Google 24 a Amazon 18 Apple 12 ⊞ Microsoft 8

The optimal solution uses a pointer-based approach that maintains position within the compressed format. Instead of expanding the entire sequence (which wastes memory), we track our current position using currentPair and consumed counters. Each next(n) operation efficiently skips through compressed segments, consuming elements as needed. This achieves O(1) space complexity while keeping the benefits of run-length encoding for large sequences.

Common Approaches

Approach	Time	Space	Notes
✓ Brute Force (Expand All Elements)	O(S) for initialization where S is sum of all counts, O(n) for next(n)	O(S)	Expand the entire RLE sequence into individual elements during initialization
Optimal Pointer-Based Iterator	O(1) for initialization, O(k) for next(n) where k is pairs traversed	O(1)	Maintain position pointers in the compressed format and skip efficiently through segments

Brute Force (Expand All Elements) — Algorithm Steps

During initialization, expand all [count, value] pairs into individual elements
Store all expanded elements in an array or list
Maintain a current index pointer
For next(n), advance the pointer by n positions and return the element at that position

Visualization

Tap to expand

Step-by-Step Walkthrough

Parse Encoding

Read [3,8,0,9,2,5] as pairs: (3,8), (0,9), (2,5)

Expand Elements

Create array: [8,8,8,5,5] from the pairs

Track Position

Use index pointer to track current position during next() calls

Code -

solution.c — C

typedef struct {
    int* elements;
    int size;
    int index;
} RLEIterator;

RLEIterator* rLEIteratorCreate(int* encoding, int encodingSize) {
    RLEIterator* obj = (RLEIterator*)malloc(sizeof(RLEIterator));
    obj->elements = (int*)malloc(100000 * sizeof(int));
    obj->size = 0;
    obj->index = 0;
    
    // Expand all encoded pairs
    for (int i = 0; i < encodingSize; i += 2) {
        int count = encoding[i];
        int value = encoding[i + 1];
        for (int j = 0; j < count; j++) {
            obj->elements[obj->size++] = value;
        }
    }
    return obj;
}

int rLEIteratorNext(RLEIterator* obj, int n) {
    obj->index += n;
    if (obj->index > obj->size) {
        return -1;
    }
    return obj->elements[obj->index - 1];
}

void rLEIteratorFree(RLEIterator* obj) {
    free(obj->elements);
    free(obj);
}

Time & Space Complexity

Time Complexity

⏱️

O(S) for initialization where S is sum of all counts, O(n) for next(n)

We must expand every single element during initialization, making it linear in the total expanded size

✓ Linear Growth

Space Complexity

O(S)

We store every expanded element, using space proportional to the total uncompressed size

✓ Linear Space

28.4K Views

Medium Frequency

~15 min Avg. Time

891 Likes

Ln 1, Col 1

Smart Actions

💡 Explanation

AI Ready

💡 Suggestion Tab to accept Esc to dismiss

// Output will appear here after running code

Code Editor Closed

Click the red button to reopen

Input & Output

Constraints

Visualization

Related Problems

Common Approaches

Brute Force (Expand All Elements) — Algorithm Steps

Visualization

Code -

Time & Space Complexity

Select Compiler