Why BST Inorder Predecessor in DSA Go?

The Big Idea

Discover how to instantly find the 'just before' value in a sorted tree without scanning everything!

The Scenario

Imagine you have a family tree drawn on paper, and you want to find the person who came just before someone else in the family history. Doing this by scanning the whole paper every time is tiring and confusing.

The Problem

Manually searching for the previous person means checking many names one by one, which takes a lot of time and can easily lead to mistakes or missing someone.

The Solution

The BST Inorder Predecessor helps you quickly find the person who comes just before another in a sorted family tree, without checking everyone. It uses the tree's order to jump straight to the right spot.

Before vs After

✗ Before

func findPredecessorManual(tree *Node, target int) *Node {
    // Scan all nodes in order and remember previous
    var previous *Node
    var result *Node
    inorder(tree, func(n *Node) {
        if n.value == target {
            result = previous
        }
        previous = n
    })
    return result
}

✓ After

func findInorderPredecessor(root *Node, target int) *Node {
    var predecessor *Node
    current := root
    for current != nil {
        if target <= current.value {
            current = current.left
        } else {
            predecessor = current
            current = current.right
        }
    }
    return predecessor
}

What It Enables

This lets you find the immediate smaller value in a sorted tree instantly, making searches and updates much faster and smarter.

Real Life Example

In a contact list sorted by names, finding the contact just before a given name helps in quick navigation and suggestions without scanning the whole list.

Key Takeaways

Manual search is slow and error-prone.

BST Inorder Predecessor uses tree order to find the previous value efficiently.

This improves speed and accuracy in sorted data operations.

Practice

1. What is the inorder predecessor of a node in a Binary Search Tree (BST)?

easy

A. The node with the smallest value larger than the given node

B. The node with the largest value smaller than the given node

C. The left child of the given node

D. The right child of the given node

Solution

1. Step 1: Understand inorder traversal in BST

   Inorder traversal visits nodes in ascending order of their values.

2. Step 2: Define inorder predecessor

   The inorder predecessor of a node is the node that comes just before it in this ascending order, meaning it has the largest value smaller than the node.

3. Final Answer:

   The node with the largest value smaller than the given node -> Option B

4. Quick Check:

   Inorder predecessor = largest smaller value [OK]

Hint: Predecessor is largest smaller value in BST [OK]

Common Mistakes:

• Confusing predecessor with successor
• Thinking predecessor is always left child
• Assuming predecessor is the parent node

2. Which of the following Go function signatures correctly represents a function to find the inorder predecessor in a BST node struct named Node?

easy

A. func inorderPredecessor(root *Node, key int) *Node

B. func inorderPredecessor(key int) Node

C. func inorderPredecessor(root Node, key int) Node

D. func inorderPredecessor(root *Node) int

Solution

1. Step 1: Analyze function parameters and return type

   The function needs the BST root pointer and the key to find predecessor for, and returns a pointer to the predecessor node.

2. Step 2: Match with options

   func inorderPredecessor(root *Node, key int) *Node matches this: it takes *Node root, int key, and returns *Node.

3. Final Answer:

   func inorderPredecessor(root *Node, key int) *Node -> Option A

4. Quick Check:

   Pointer root and key input, pointer node output [OK]

Hint: Use pointer receiver and return pointer for BST nodes [OK]

Common Mistakes:

• Passing root by value instead of pointer
• Returning node value instead of node pointer
• Missing key parameter to identify target node

3. Given the following BST and code snippet, what will be printed?

type Node struct {
    Val int
    Left, Right *Node
}

func inorderPredecessor(root *Node, key int) *Node {
    var predecessor *Node
    curr := root
    for curr != nil {
        if key <= curr.Val {
            curr = curr.Left
        } else {
            predecessor = curr
            curr = curr.Right
        }
    }
    return predecessor
}

func main() {
    root := &Node{Val: 20}
    root.Left = &Node{Val: 10}
    root.Right = &Node{Val: 30}
    root.Left.Left = &Node{Val: 5}
    root.Left.Right = &Node{Val: 15}

    pred := inorderPredecessor(root, 15)
    if pred != nil {
        fmt.Println(pred.Val)
    } else {
        fmt.Println("No predecessor")
    }
}

medium

A. No predecessor

B. 5

C. 15

D. 10

Solution

1. Step 1: Trace the inorderPredecessor function for key=15

   Start at root (20). Since 15 <= 20, move left to 10. Since 15 > 10, set predecessor=10, move right to 15. Since 15 <= 15, move left (nil). Loop ends.

2. Step 2: Return predecessor node value

   Predecessor is node with value 10, so print 10.

3. Final Answer:

   10 -> Option D

4. Quick Check:

   Largest smaller than 15 is 10 [OK]

Hint: Move left if key ≤ node, else update predecessor and move right [OK]

Common Mistakes:

• Returning the key itself as predecessor
• Confusing predecessor with successor
• Not updating predecessor correctly when moving right

4. The following Go function is intended to find the inorder predecessor of a node with value key in a BST. What is the bug?

func inorderPredecessor(root *Node, key int) *Node {
    var predecessor *Node
    curr := root
    for curr != nil {
        if key < curr.Val {
            curr = curr.Left
        } else {
            predecessor = curr
            curr = curr.Right
        }
    }
    return predecessor
}

medium

A. The function should return curr instead of predecessor

B. The predecessor variable should be reset inside the loop

C. The condition should be key <= curr.Val to handle equal keys correctly

D. The loop should use recursion instead of iteration

Solution

1. Step 1: Analyze the condition in the loop

   The current condition is key < curr.Val, which skips updating predecessor when key equals curr.Val.

2. Step 2: Correct the condition to include equality

   Changing to key <= curr.Val ensures that when key equals curr.Val, we move left without updating predecessor, which is correct for inorder predecessor logic.

3. Final Answer:

   The condition should be key <= curr.Val to handle equal keys correctly -> Option C

4. Quick Check:

   Use <= to handle equal keys properly [OK]

Hint: Use <= in condition to handle equal keys correctly [OK]

Common Mistakes:

• Using < instead of <= causes wrong predecessor for equal keys
• Resetting predecessor inside loop loses previous valid value
• Returning curr instead of predecessor returns wrong node

5. You have a BST where each node has a pointer to its parent. How would you find the inorder predecessor of a given node n efficiently without starting from the root? Choose the best approach.

hard

A. If n has a left child, find the rightmost node in its left subtree; else, move up using parent pointers until you find a node which is the right child of its parent

B. Always start from the root and do a full inorder traversal to find predecessor

C. If n has a right child, find the leftmost node in its right subtree; else, move up using parent pointers until you find a node which is the left child of its parent

D. Return the parent node directly as the predecessor

Solution

1. Step 1: Check if node has left subtree

   If n has a left child, the predecessor is the rightmost node in that left subtree.

2. Step 2: If no left child, move up using parent pointers

   Move up until you find a node that is the right child of its parent; that parent is the predecessor.

3. Final Answer:

   If n has left child, find rightmost in left subtree; else move up until node is right child -> Option A

4. Quick Check:

   Use left subtree or climb parents to find predecessor [OK]

Hint: Use left subtree or climb parents via right child link [OK]

Common Mistakes:

• Starting from root wastes time
• Confusing predecessor with successor logic
• Returning parent directly without checks