What if you could find anything in a huge list almost instantly, without checking every item?
Why BST Search Operation in DSA Rust?
Imagine you have a huge phone book with thousands of names, and you want to find one person's phone number. If you look at each name one by one from the start, it will take a very long time.
Searching manually through a long list is slow and tiring. You might lose your place or skip names by mistake. It wastes time and can cause frustration.
A Binary Search Tree (BST) organizes data like a smart phone book. It splits the list so you can quickly jump to the right half or left half, cutting down the search time drastically.
fn search_manual(list: &[i32], target: i32) -> bool {
for &item in list {
if item == target {
return true;
}
}
false
}fn search_bst(node: &Option<Box<Node>>, target: i32) -> bool {
match node {
None => false,
Some(n) => {
if target == n.value {
true
} else if target < n.value {
search_bst(&n.left, target)
} else {
search_bst(&n.right, target)
}
}
}
}It lets you find any item quickly, even in huge collections, saving time and effort.
When you search for a contact on your phone, the system uses a method like BST search to find the name fast instead of checking every contact one by one.
Manual search is slow and error-prone for large data.
BST search uses order to jump closer to the target quickly.
This makes searching efficient and reliable.
Practice
Solution
Step 1: Understand the purpose of BST search
The search operation checks if a specific value is present in the BST by comparing values and moving left or right accordingly.Step 2: Differentiate from other BST operations
Insertion adds new nodes, deletion removes nodes, and counting nodes is a separate operation. Search only checks presence.Final Answer:
Finds whether a given value exists in the BST -> Option DQuick Check:
Search = Find value [OK]
- Confusing search with insert or delete
- Thinking search counts nodes
- Assuming search modifies the tree
Solution
Step 1: Identify method receiver and return type
Search should borrow the tree immutably (&self) and return true/false (bool) indicating presence.Step 2: Check parameters and return correctness
Value parameter is i32, and return type is bool. Mutable borrow or returning Node is incorrect for simple search.Final Answer:
fn search(&self, value: i32) -> bool -> Option CQuick Check:
Immutable borrow + bool return = fn search(&self, value: i32) -> bool [OK]
- Using &mut self instead of &self
- Returning Node instead of bool
- Missing self parameter
struct Node {
value: i32,
left: Option,
right: Option,
}
impl Node {
fn search(&self, val: i32) -> bool {
if val == self.value {
true
} else if val < self.value {
match &self.left {
Some(left_node) => left_node.search(val),
None => false,
}
} else {
match &self.right {
Some(right_node) => right_node.search(val),
None => false,
}
}
}
}
fn main() {
let root = Node {
value: 5,
left: Some(Box::new(Node { value: 3, left: None, right: None })),
right: Some(Box::new(Node { value: 8, left: None, right: None })),
};
println!("{}", root.search(7));
}Solution
Step 1: Trace search for value 7 starting at root 5
7 > 5, so search right subtree with root 8.Step 2: Search right subtree node with value 8 for 7
7 < 8, so search left subtree of node 8, which is None, so returns false.Final Answer:
false -> Option AQuick Check:
7 not found in tree = false [OK]
- Assuming 7 is found because 8 exists
- Confusing left and right subtree directions
- Ignoring None case returns false
fn search(&self, val: i32) -> bool {
if val == self.value {
true
} else if val < self.value {
self.left.as_ref().unwrap().search(val)
} else {
self.right.as_ref().unwrap().search(val)
}
}Solution
Step 1: Analyze use of unwrap() on Option
unwrap() assumes the Option is Some, but if child is None, it causes runtime panic.Step 2: Understand safe alternative
Should check if child exists using match or if let before calling search to avoid panic.Final Answer:
Using unwrap() without checking if child exists can cause panic -> Option AQuick Check:
unwrap() on None = panic [OK]
- Ignoring possibility of None causing panic
- Thinking unwrap() is safe always
- Confusing return types
Solution
Step 1: Understand duplicates on right subtree
Duplicates are stored on the right, so if val equals node value, we found it; else if val > node, search right subtree.Step 2: Modify search to check current node and right subtree for duplicates
If val equals node value, return true immediately. If val > node value, search right subtree. If val < node value, search left subtree.Final Answer:
Search left subtree if val < node, else search both right subtree and current node for val -> Option BQuick Check:
Duplicates on right: check current and right subtree [OK]
- Ignoring duplicates on right subtree
- Searching only one subtree without checking current node
- Searching left subtree unnecessarily for duplicates
Ready to prove it?
Pass the test and this pattern moves unknown
