Collision Handling Using Open Addressing Linear Probing in DSA Go - Time & Space Complexity
When we use open addressing with linear probing to handle collisions in a hash table, we want to know how fast insertions and searches happen as the table fills up.
How does the time to find or add an item change when more items are stored?
Analyze the time complexity of the following code snippet.
func linearProbingInsert(table []int, key int) {
size := len(table)
index := key % size
for i := 0; i < size; i++ {
probeIndex := (index + i) % size
if table[probeIndex] == -1 {
table[probeIndex] = key
return
}
}
}
This code tries to insert a key into a hash table using linear probing to find the next empty slot if a collision occurs.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The for-loop that checks each slot starting from the hashed index until it finds an empty slot.
- How many times: In the worst case, it can check every slot in the table once (up to n times, where n is table size).
As the table size and number of stored keys grow, the number of checks needed to find an empty slot or a key grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Up to 10 checks |
| 100 | Up to 100 checks |
| 1000 | Up to 1000 checks |
Pattern observation: The number of operations can grow linearly with the number of slots checked when collisions happen often.
Time Complexity: O(n)
This means in the worst case, inserting or searching can take time proportional to the size of the table because it may check many slots one by one.
[X] Wrong: "Insertion always takes constant time because hashing gives direct access."
[OK] Correct: When collisions happen, linear probing may check many slots, so time can grow with table size, not stay constant.
Understanding how collision handling affects time helps you explain trade-offs in hash tables and shows you can analyze real data structure performance.
"What if we changed linear probing to quadratic probing? How would the time complexity change?"
Practice
linear probing in collision handling for hash tables?Solution
Step 1: Understand collision handling
When two keys hash to the same slot, a collision occurs and must be resolved.Step 2: Explain linear probing method
Linear probing resolves collisions by checking the next slot in order until an empty one is found.Final Answer:
If a collision occurs, check the next slot sequentially until an empty slot is found. -> Option AQuick Check:
Linear probing = sequential slot check [OK]
- Confusing linear probing with chaining
- Thinking linear probing replaces existing elements
- Assuming table size doubles on collision
m when current index is i?Solution
Step 1: Understand linear probing index calculation
Linear probing moves to the next slot by adding 1 to the current index.Step 2: Apply modulo to wrap around
To stay within table bounds, use modulo with table size: (i + 1) % m.Final Answer:
(i + 1) % m -> Option AQuick Check:
Next index = (current + 1) mod size [OK]
- Using multiplication instead of addition
- Not using modulo causing out-of-bound errors
- Subtracting instead of adding for next slot
h(k) = k % 5. What is the final state of the table?Solution
Step 1: Calculate initial positions
h(7) = 7 % 5 = 2, h(12) = 12 % 5 = 2, h(17) = 17 % 5 = 2.Step 2: Insert keys using linear probing
Insert 7 at index 2. For 12, index 2 is taken, so check index 3 (empty), insert 12. For 17, indexes 2 and 3 taken, check index 4 (empty), insert 17.Final Answer:
[null, null, 7, 12, 17] -> Option DQuick Check:
All keys placed sequentially after collision [OK]
- Placing keys at wrong indices ignoring collisions
- Not applying modulo for hash function
- Assuming keys overwrite existing ones
func insert(table []int, key int) {
m := len(table)
index := key % m
for table[index] != -1 {
index = (index + 1) % m
}
table[index] = key
}
// Initial table: [-1, -1, -1, -1, -1]
// Insert keys: 3, 8, 13
Solution
Step 1: Analyze loop condition and termination
The loop continues while the slot is occupied (not -1). If the table is full, the loop never ends.Step 2: Identify missing full table check
There is no check to stop after probing all slots, so infinite loop can occur if table is full.Final Answer:
The code does not handle the case when the table is full, causing an infinite loop. -> Option BQuick Check:
Missing full table check causes infinite loop [OK]
- Ignoring full table condition
- Confusing initial empty slot value
- Misusing modulo operation
h(k) = k % 7. You insert keys 10, 20, 15, 7, 32 in this order. After these insertions, you want to insert key 24. Which index will key 24 be placed at?Solution
Step 1: Insert keys and find their positions
h(10)=3, insert at 3. h(20)=6, insert at 6. h(15)=1, insert at 1. h(7)=0, insert at 0. h(32)=4, insert at 4.Step 2: Find position for key 24
h(24)=3, but index 3 occupied by 10. Check next index 4 (occupied by 32), then 5 (empty), so insert at 5.Final Answer:
Index 5 -> Option CQuick Check:
Linear probe from 3 to 5 for key 24 [OK]
- Stopping at first collision without probing
- Not applying modulo for wrap-around
- Misplacing keys ignoring occupied slots
Ready to prove it?
Pass the test and this pattern moves unknown
