Why Trie Exists and What Hash Map Cannot Do for Strings in DSA C - Quick Recap

Recall & Review

beginner

What is a Trie data structure?

A Trie is a tree-like data structure that stores strings by sharing common prefixes. Each node represents a character, and paths from root to leaves form words.

beginner

Why can't a hash map efficiently handle prefix searches on strings?

Hash maps store keys independently and do not share prefixes. So, searching for all keys with a common prefix requires checking every key, which is slow.

intermediate

How does a Trie improve prefix search compared to a hash map?

Trie nodes share prefixes, so searching for all words with a prefix is fast by following the prefix path once, then exploring its subtree.

beginner

What is a real-life example where Trie is better than a hash map?

Autocomplete in search engines uses Trie to quickly find all words starting with typed letters, which hash maps cannot do efficiently.

intermediate

What is a limitation of hash maps when used for string keys?

Hash maps do not support ordered traversal or prefix queries efficiently because keys are stored without structure linking similar prefixes.

What does each node in a Trie represent?

A A whole string

B A character of a string

C A number

D A hash value

Each node in a Trie represents a single character of a string.

Why is prefix search slow in a hash map?

A Because hash maps use trees internally

B Because hash maps sort keys alphabetically

C Because hash maps store keys independently without prefix sharing

D Because hash maps store keys as linked lists

Hash maps store keys independently, so prefix search requires checking all keys.

Which data structure is best for autocomplete features?

A Trie

B Hash Map

C Stack

D Queue

Trie efficiently supports prefix search needed for autocomplete.

What is a key advantage of Trie over hash map for strings?

A Supports fast prefix queries

B Uses less memory always

C Faster insertion for all data types

D Automatically sorts keys numerically

Trie supports fast prefix queries by sharing prefixes in nodes.

Which operation is inefficient in hash maps for string keys?

A Inserting a new key

B Finding a key exactly

C Deleting a key

D Finding all keys with a given prefix

Hash maps cannot efficiently find all keys sharing a prefix.

Explain why Trie data structure exists and what problem it solves that hash maps cannot for strings.

Think about how strings with common beginnings are stored and searched.

Describe a real-world scenario where using a Trie is better than a hash map for string operations.

Consider typing in a search box and getting suggestions.

Practice

1. Why do we use a Trie data structure instead of a Hash Map for storing strings?

easy

A. Because Trie is faster for all types of data retrieval

B. Because Trie supports efficient prefix search which Hash Map cannot do easily

C. Because Hash Map cannot store strings as keys

D. Because Trie uses less memory than Hash Map for all data types

Solution

1. Step 1: Understand Trie and Hash Map capabilities

   Trie stores strings in a tree form allowing prefix-based queries efficiently. Hash Map stores key-value pairs but does not support prefix search efficiently.

2. Step 2: Compare prefix search ability

   Trie can quickly find all strings starting with a prefix. Hash Map requires checking all keys or extra structures, which is inefficient.

3. Final Answer:

   Because Trie supports efficient prefix search which Hash Map cannot do easily -> Option B

4. Quick Check:

   Prefix search = Trie [OK]

Hint: Trie excels at prefix search, Hash Map does not [OK]

Common Mistakes:

• Thinking Hash Map cannot store strings as keys
• Believing Trie always uses less memory
• Assuming Trie is faster for all queries

2. Which of the following is the correct way to declare a Trie node structure in C?

easy

A. struct TrieNode { char* children; int isEndOfWord; };

B. struct TrieNode { int children; bool isEndOfWord; };

C. struct TrieNode { struct TrieNode* children[26]; bool isEndOfWord; };

D. struct TrieNode { struct TrieNode children; bool isEndOfWord; };

Solution

1. Step 1: Understand Trie node structure

   A Trie node typically has an array of pointers to child nodes (for each alphabet letter) and a boolean to mark end of word.

2. Step 2: Check each option

   struct TrieNode { struct TrieNode* children[26]; bool isEndOfWord; }; correctly declares an array of 26 pointers and a boolean flag. Others have wrong types or missing pointers.

3. Final Answer:

   struct TrieNode { struct TrieNode* children[26]; bool isEndOfWord; }; -> Option C

4. Quick Check:

   Trie node = array of pointers + bool [OK]

Hint: Trie node has pointer array for children and bool flag [OK]

Common Mistakes:

• Using int instead of pointer array for children
• Declaring children as single struct instead of array
• Confusing data types for isEndOfWord

3. What is the output of the following C code snippet that inserts "cat" and "car" into a Trie and checks prefix "ca"?

insert("cat");
insert("car");
bool result = startsWith("ca");
printf("%d", result);

medium

A. 1

B. 0

C. Compilation error

D. Undefined behavior

Solution

1. Step 1: Understand insert and startsWith functions

   Inserting "cat" and "car" adds nodes for 'c', 'a', 't' and 'r'. startsWith("ca") checks if any word starts with "ca".

2. Step 2: Check if prefix "ca" exists

   Both words start with "ca", so startsWith("ca") returns true (1).

3. Final Answer:

   1 -> Option A

4. Quick Check:

   Prefix "ca" found = 1 [OK]

Hint: If words share prefix, startsWith returns 1 [OK]

Common Mistakes:

• Assuming startsWith returns 0 if prefix is partial
• Confusing insert with search function
• Ignoring that both words share prefix

4. Given this buggy Trie insertion code in C, what is the main error?

void insert(struct TrieNode* root, char* word) {
  struct TrieNode* node = root;
  for (int i = 0; word[i] != '\0'; i++) {
    int index = word[i] - 'a';
    if (node->children[index] == NULL) {
      node->children[index] = malloc(sizeof(struct TrieNode));
    }
    node = node->children[index];
  }
  node->isEndOfWord = true;
}

medium

A. isEndOfWord is set before loop

B. Index calculation is incorrect

C. Root node is not passed correctly

D. New nodes are not initialized to NULL

Solution

1. Step 1: Analyze node allocation

   When malloc allocates new TrieNode, its children pointers and isEndOfWord are uninitialized garbage values.

2. Step 2: Identify missing initialization

   New nodes must have children array set to NULL and isEndOfWord set to false to avoid errors during traversal.

3. Final Answer:

   New nodes are not initialized to NULL -> Option D

4. Quick Check:

   Uninitialized nodes cause bugs [OK]

Hint: Always initialize new Trie nodes after malloc [OK]

Common Mistakes:

• Thinking index calculation is wrong
• Setting isEndOfWord too early
• Assuming root node passing is incorrect

5. You want to store a large dictionary of words and quickly find all words starting with a given prefix. Why is Trie a better choice than Hash Map, and what is a key limitation of Hash Map in this scenario?

hard

A. Trie allows prefix search in O(k) time; Hash Map cannot do prefix search efficiently

B. Trie uses less memory; Hash Map cannot store strings as keys

C. Hash Map is slower for exact matches; Trie cannot store full words

D. Hash Map requires sorting keys; Trie automatically sorts keys

Solution

1. Step 1: Understand prefix search complexity

   Trie can find all words with a prefix in time proportional to prefix length (O(k)), independent of dictionary size.

2. Step 2: Identify Hash Map limitation

   Hash Map supports exact key lookup efficiently but cannot efficiently find keys by prefix without scanning all keys.

3. Final Answer:

   Trie allows prefix search in O(k) time; Hash Map cannot do prefix search efficiently -> Option A

4. Quick Check:

   Prefix search = Trie advantage [OK]

Hint: Trie = fast prefix search; Hash Map = exact match only [OK]

Common Mistakes:

• Believing Hash Map cannot store strings as keys
• Thinking Trie uses less memory always
• Confusing sorting with prefix search