Maximum Width of Binary Tree in DSA Rust - Execution Trace

Concept Flow - Maximum Width of Binary Tree

Start at root node

↓

Initialize queue with root and index 0

↓

While queue not empty

↓

For each level: get first and last index

↓

Calculate width = last_index - first_index + 1

↓

Update max width if current width is larger

↓

Add children to queue with updated indices

↓

Repeat for next level

↓

Return max width found

We traverse the tree level by level, tracking node positions to find the widest level.

Execution Sample

DSA Rust

fn width_of_binary_tree(root: Option<Rc<RefCell<TreeNode>>>) -> i32 {
    use std::collections::VecDeque;
    use std::rc::Rc;
    use std::cell::RefCell;

    let mut max_width = 0;
    let mut queue = VecDeque::new();
    if root.is_none() {
        return 0;
    }
    queue.push_back((root.unwrap(), 0));
    while !queue.is_empty() {
        let level_length = queue.len();
        let first_index = queue.front().unwrap().1;
        let last_index = queue.back().unwrap().1;
        max_width = max_width.max(last_index - first_index + 1);

        for _ in 0..level_length {
            let (node, index) = queue.pop_front().unwrap();
            let node_ref = node.borrow();
            if let Some(left) = node_ref.left.clone() {
                queue.push_back((left, 2 * (index - first_index)));
            }
            if let Some(right) = node_ref.right.clone() {
                queue.push_back((right, 2 * (index - first_index) + 1));
            }
        }
    }
    max_width as i32
}

This code uses a queue to traverse each level of the tree and track node indices to compute width.

Execution Table

Step	Operation	Nodes in Queue (node_val:index)	Pointer Changes	Visual State
1	Initialize queue with root (1) at index 0	[(1:0)]	queue.push_back((1,0))	Level 0: [1:0]
2	Process level 0, length=1	[(1:0)]	pop (1:0)	Level 0 processed, width=1
3	Add children of 1: left(3), right(2)	[(3:0), (2:1)]	push (3,0), push (2,1)	Level 1: [3:0, 2:1]
4	Process level 1, length=2	[(3:0), (2:1)]	pop (3:0), pop (2:1)	Level 1 processed, width=2
5	Add children: 3->left(5), 3->right(3), 2->right(9)	[(5:0), (3:1), (9:3)]	push (5,0), push (3,1), push (9,3)	Level 2: [5:0, 3:1, 9:3]
6	Process level 2, length=3	[(5:0), (3:1), (9:3)]	pop (5:0), pop (3:1), pop (9:3)	Level 2 processed, width=4
7	Add children: 5->left(6), 9->right(7)	[(6:0), (7:7)]	push (6,0), push (7,7)	Level 3: [6:0, 7:7]
8	Process level 3, length=2	[(6:0), (7:7)]	pop (6:0), pop (7:7)	Level 3 processed, width=8
9	No more children to add	[]	queue empty	Traversal complete, max width=8

💡 Queue is empty, all levels processed

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7	Final
max_width	0	0	2	4	8	8
queue	[]	[(1:0)]	[(3:0), (2:1)]	[(5:0), (3:1), (9:3)]	[(6:0), (7:7)]	[]

Key Moments - 3 Insights

Why do we assign indices to nodes in the queue?

Indices help calculate the width by tracking the position of nodes as if the tree was a complete binary tree. See execution_table rows 3, 5, and 7 where indices are assigned and used.

Why does the width calculation use last_index - first_index + 1?

Because indices start at 0, the width is the distance between first and last plus one. This is shown in execution_table rows 2, 4, 6, and 8 where widths 1, 2, 4, and 8 are calculated.

Why do some indices jump (like from 3:1 to 9:3)?

Indices reflect positions in a complete tree, so missing nodes cause gaps. This is why 9 has index 3, skipping index 2. See execution_table row 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the max_width after processing level 2?

A 2

B 4

C 8

D 1

💡 Hint

Check execution_table row 6 under 'Visual State' and 'max_width' in variable_tracker after Step 5

At which step does the queue become empty, ending the traversal?

A Step 7

B Step 8

C Step 9

D Step 6

💡 Hint

Look at execution_table row 9 where queue is empty and traversal ends

If the root had no children, what would be the max_width after Step 2?

A 0

B 1

C 2

D Undefined

💡 Hint

See execution_table row 2 where width is calculated as 1 for root only

Concept Snapshot

Maximum Width of Binary Tree:
- Traverse tree level by level using a queue
- Assign indices to nodes as if in a complete tree
- Width = last_index - first_index + 1 per level
- Track max width across all levels
- Return max width after traversal

Full Transcript

This concept finds the maximum width of a binary tree by traversing it level by level. We use a queue to hold nodes along with their indices, which represent their position in a complete binary tree. At each level, we calculate the width by subtracting the first node's index from the last node's index and adding one. We update the maximum width if the current level's width is larger. We continue until all levels are processed and return the maximum width found.

Practice

1. What does the "maximum width" of a binary tree represent?

easy

A. The total number of nodes in the tree

B. The height of the tree from root to the deepest leaf

C. The largest number of nodes present at any single level of the tree

D. The sum of values of all nodes at the widest level

Solution

1. Step 1: Understand the definition of width in a binary tree

   The width of a binary tree at a level is the count of nodes present at that level.

2. Step 2: Identify maximum width

   The maximum width is the largest such count among all levels.

3. Final Answer:

   The largest number of nodes present at any single level of the tree -> Option C

4. Quick Check:

   Width = max nodes at any level [OK]

Hint: Width means count of nodes at widest level [OK]

Common Mistakes:

• Confusing width with tree height
• Thinking width is sum of node values
• Mixing width with total nodes count

2. Which Rust data structure is most suitable to track nodes level by level when calculating maximum width of a binary tree?

easy

A. VecDeque (double-ended queue)

B. Vec (vector)

C. HashMap

D. BTreeSet

Solution

1. Step 1: Identify the need for level order traversal

   To find maximum width, we visit nodes level by level, which is a breadth-first search (BFS).

2. Step 2: Choose data structure for BFS

   BFS uses a queue to process nodes in FIFO order. Rust's VecDeque supports efficient push/pop from both ends.

3. Final Answer:

   VecDeque (double-ended queue) -> Option A

4. Quick Check:

   Use queue (VecDeque) for BFS traversal [OK]

Hint: Use VecDeque for efficient queue operations in BFS [OK]

Common Mistakes:

• Using Vec which is inefficient for queue operations
• Using HashMap which is unordered
• Using BTreeSet which is for sorted unique elements

3. Given the following Rust code snippet for maximum width calculation, what is the printed output?

struct TreeNode {
    val: i32,
    left: Option,
    right: Option,
}

fn max_width(root: Option) -> usize {
    use std::collections::VecDeque;
    if root.is_none() { return 0; }
    let mut queue = VecDeque::new();
    queue.push_back(root.unwrap());
    let mut max_width = 0;
    while !queue.is_empty() {
        let level_size = queue.len();
        max_width = max_width.max(level_size);
        for _ in 0..level_size {
            let node = queue.pop_front().unwrap();
            if let Some(left) = node.left {
                queue.push_back(left);
            }
            if let Some(right) = node.right {
                queue.push_back(right);
            }
        }
    }
    max_width
}

fn main() {
    let root = Some(Box::new(TreeNode {
        val: 1,
        left: Some(Box::new(TreeNode { val: 2, left: None, right: None })),
        right: Some(Box::new(TreeNode {
            val: 3,
            left: Some(Box::new(TreeNode { val: 4, left: None, right: None })),
            right: None,
        })),
    }));
    println!("{}", max_width(root));
}

medium

A. 3

B. 2

C. 4

D. 1

Solution

1. Step 1: Analyze the tree structure

   Level 1: Node 1 (1 node) Level 2: Nodes 2 and 3 (2 nodes) Level 3: Node 4 (1 node)

2. Step 2: Calculate maximum width

   Widths per level: 1, 2, 1 Maximum width is 2.

3. Final Answer:

   2 -> Option B

4. Quick Check:

   Max width = 2 nodes at level 2 [OK]

Hint: Count nodes per level, pick max count [OK]

Common Mistakes:

• Counting total nodes instead of per level
• Ignoring empty children in width calculation
• Confusing node values with count

4. The following Rust code attempts to compute the maximum width of a binary tree but has a bug. What is the bug?

fn max_width(root: Option) -> usize {
    use std::collections::VecDeque;
    if root.is_none() { return 0; }
    let mut queue = VecDeque::new();
    queue.push_back(root.unwrap());
    let mut max_width = 0;
    while !queue.is_empty() {
        let level_size = queue.len();
        max_width = max_width.max(level_size);
        for _ in 0..level_size {
            let node = queue.pop_front().unwrap();
            if node.left.is_some() {
                queue.push_back(node.left.unwrap());
            }
            if node.right.is_some() {
                queue.push_back(node.right.unwrap());
            }
        }
    }
    max_width
}

medium

A. Not handling empty tree case

B. Using VecDeque instead of Vec causes performance issues

C. Not updating max_width inside the loop

D. Calling unwrap() on Option without checking causes panic

Solution

1. Step 1: Identify unsafe unwrap calls

   Calling unwrap() on node.left or node.right without safely extracting causes panic if None.

2. Step 2: Correct approach

   Use if let Some(left) = node.left { queue.push_back(left); } to safely handle Options.

3. Final Answer:

   Calling unwrap() on Option without checking causes panic -> Option D

4. Quick Check:

   Unsafe unwrap causes runtime panic [OK]

Hint: Use if let to safely unwrap Options [OK]

Common Mistakes:

• Using unwrap() directly on Option fields
• Ignoring empty tree check (though present here)
• Confusing VecDeque with Vec performance

5. You want to find the maximum width of a binary tree where some levels have missing nodes between others (e.g., a sparse tree). Which approach correctly calculates the maximum width including gaps between nodes? A common method is to assign position indices to nodes as if the tree was a complete binary tree. Which Rust code snippet correctly updates the maximum width using position indices during level order traversal?

use std::collections::VecDeque;

fn max_width_with_positions(root: Option) -> usize {
    if root.is_none() { return 0; }
    let mut max_width = 0;
    let mut queue = VecDeque::new();
    queue.push_back((root.unwrap(), 0usize));
    while !queue.is_empty() {
        let level_length = queue.len();
        let first_index = queue.front().unwrap().1;
        let last_index;
        for i in 0..level_length {
            let (node, idx) = queue.pop_front().unwrap();
            let idx = idx - first_index; // normalize to prevent overflow
            if node.left.is_some() {
                queue.push_back((node.left.unwrap(), 2 * idx + 1));
            }
            if node.right.is_some() {
                queue.push_back((node.right.unwrap(), 2 * idx + 2));
            }
            if i == level_length - 1 {
                last_index = idx;
            }
        }
        max_width = max_width.max(last_index + 1);
    }
    max_width
}

hard

A. Normalize indices by subtracting first index at each level to avoid overflow

B. Use raw indices without normalization to get exact positions

C. Ignore indices and count nodes only for width

D. Use depth instead of indices for width calculation

Solution

1. Step 1: Understand position indexing

   Assigning indices as if complete binary tree helps measure width including gaps.

2. Step 2: Normalize indices to prevent overflow

   Subtracting first index at each level keeps indices small and prevents usize overflow.

3. Step 3: Calculate width as last_index - first_index + 1

   Using normalized indices, width = last_index + 1 at each level.

4. Final Answer:

   Normalize indices by subtracting first index at each level to avoid overflow -> Option A

5. Quick Check:

   Index normalization prevents overflow and calculates width correctly [OK]

Hint: Subtract first index each level to keep indices small [OK]

Common Mistakes:

• Not normalizing indices causing overflow
• Ignoring gaps by counting nodes only
• Using depth instead of position indices