/wiki / strings

_Index_of_strings

2026-09-02T05:29:25.227Z

anagram-detection-via-hashing ascii-math-elimination character-hashing-use-cases character-to-index-mapping direct-array-access first-non-repeating-character frequency-array-vs-hash-map frequency-array hash-collision-overhead hash-map-flexibility hashing-retrieval-phase hashing-store-phase index-to-character-conversion interview-decision-framework known-range-assumption map-traversal-method memory-efficiency-array most-frequent-character strings-moc strings-summary two-phase-hashing-patterns two-phase-hashing unordered-map-frequency unordered-map-non-determinism

anagram-detection-via-hashing

2026-07-05T00:00:00.000Z

Formal Definition

Anagram detection determines whether two strings are permutations of each other — that is, whether they contain the same characters with the same frequencies. The hash-based approach builds frequency structures for both strings and compares them. Anagrams produce identical frequency maps.

$\text{are\_anagrams}(S_1, S_2) \iff \forall c, \text{freq}_{S_1}(c) = \text{freq}_{S_2}(c)$

Explanation

Two strings are anagrams if one can be rearranged to form the other. The simplest correct approach is to count character frequencies for both strings and compare. This elegantly demonstrates the two-phase hashing pattern applied to two inputs simultaneously — Phase 1 runs twice (once per string), then Phase 2 compares the two structures.

How It Works

Build frequency array/map for string 1 (freq1)
Build frequency array/map for string 2 (freq2)
For arrays: compare element by element — all 26 slots must match
For maps: compare key-value pairs — all keys in one must exist in the other with the same values
If all counts match, the strings are anagrams

Mathematical Formulation

For strings $S_1$ and $S_2$ over alphabet $\Sigma$ :

$\text{Anagram}(S_1, S_2) \iff \forall c \in \Sigma, \text{count}(S_1, c) = \text{count}(S_2, c)$

$\text{Anagram}(S_1, S_2) \iff \sum_{c \in \Sigma} |\text{count}(S_1, c) - \text{count}(S_2, c)| = 0$

Visual Explanation

digraph anagram_detection {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
 
  S1 [label="String 1:\n'listen'"]
  S2 [label="String 2:\n'silent'"]
  P1_S1 [label="Phase 1\nBuild freq1"]
  P1_S2 [label="Phase 1\nBuild freq2"]
  F1 [label="freq1:\ne:1, i:1, l:1\nn:1, s:1, t:1"]
  F2 [label="freq2:\ne:1, i:1, l:1\nn:1, s:1, t:1"]
  COMPARE [label="Compare\nfreq1 == freq2?" shape=diamond]
  YES [label="Anagram!" fillcolor="#d4edda]
  NO [label="Not Anagram" fillcolor="#ffe5cc"]
 
  S1 -> P1_S1
  S2 -> P1_S2
  P1_S1 -> F1
  P1_S2 -> F2
  F1 -> COMPARE
  F2 -> COMPARE
  COMPARE -> YES [label="yes"]
  COMPARE -> NO [label="no"]
}

Semantic Network

Key Properties

O(n + m) time where n and m are the lengths of the two strings
O(|Σ|) space for arrays (26 slots), O(k) for maps (k distinct characters in both strings)
Two structures must be compared — doubles the Phase 1 work
Early exit possible: if lengths differ, they cannot be anagrams (check before building)
Sorting both strings and comparing is also correct but O(n log n) — hashing is faster

Connections

Built from: Hashing Retrieval Phase — comparing two structures is a Phase 2 variant
Built from: Two-Phase Hashing Paradigm — Phase 1 runs twice, then Phase 2 compares
Built from: Frequency Array — arrays are ideal for lowercase-only anagram checks
Contrasts with: Most Frequent Character — different Phase 2 goal despite same Phase 1
Contrasts with: First Non-Repeating Character — compares structures instead of re-traversing
Related: Known Range Assumption — for known alphabets, arrays are simpler than maps

Edge Cases & Gotchas

Different lengths: immediately return false — no need to build structures
Empty strings: two empty strings are anagrams (both have zero length and empty frequency maps)
Case sensitivity: “Listen” and “Silent” are not anagrams by default — convert to same case first if needed
Unicode characters: arrays cannot handle this — must use hash maps
Whitespace and punctuation: the problem typically specifies whether to ignore these
Sorting approach (O(n log n)) is simpler to code but slower — hashing is the interview-optimized answer

ascii-math-elimination

2026-07-05T00:00:00.000Z

Formal Definition

ASCII math elimination is the property of hash maps (like std::unordered_map) that they accept keys directly without requiring index conversion. Where a frequency array needs ch - 'a' to compute an array index, a hash map uses freq[ch] directly — the character itself is the key, and the hash function handles the mapping. This eliminates the need for ASCII arithmetic entirely.

Explanation

With frequency arrays, every character must go through ch - 'a' to become an array index. This assumes lowercase ASCII contiguity, breaks for mixed case, and requires a separate reverse conversion (i + 'a') for output. Hash maps bypass all of this: the character is used as-is. The hash function converts it to a bucket index internally, invisible to the programmer. This is the fundamental ergonomic advantage of hash maps over arrays.

How It Works

Declare unordered_map<char, int> freq — key type is char, value type is int
To insert: freq[ch]++ — no conversion needed, the character is the key
To query: freq[ch] — same direct access
Internally, the map calls std::hash<char>()(ch) to compute the bucket index
The programmer never sees the hash value or bucket index — it is fully abstracted

Visual Explanation

Semantic Network

Key Properties

Eliminates source of bugs: no more ch - 'a' on uppercase characters producing negative indices
Works for any character type: lowercase, uppercase, digits, punctuation, Unicode
No reverse conversion needed for output — the key is already the character
The hash function cost is the tradeoff — internal computation replaces explicit ASCII math
One less thing to think about during coding interviews — reduces cognitive load

Connections

Built from: Hash Map Flexibility — the ability to use diverse key types enables this
Builds into: Unordered Map for Frequency Counting — maps use direct keys without conversion
Contrasts with: Character-to-Index Mapping — arrays require explicit conversion; maps eliminate it
Contrasts with: Index-to-Character Conversion — maps don’t need the reverse conversion either
Related: Known Range Assumption — arrays need known ranges; maps eliminate this assumption
Related: Direct Array Access — arrays have no hashing cost but pay in conversion complexity

Edge Cases & Gotchas

The hash function is not free — for small domains (26 lowercase letters), the conversion cost of ch - 'a' is negligible while the hash function adds measurable overhead
Deleting the ASCII math does not mean deleting all constraints — the map’s hash function must handle the key type correctly (all standard types are supported in C++)
For custom key types (e.g., structs), a custom hash function must be provided — ASCII math elimination only applies to built-in types
The elimination is conceptual, not architectural — internally the map still converts the key to an index; it just hides this from the programmer

character-hashing-use-cases

2026-07-05T00:00:00.000Z

Formal Definition

Character hashing use cases are the set of string problems solvable by building a frequency structure (Phase 1) and then applying problem-specific retrieval logic (Phase 2). Common patterns include finding the most frequent character, detecting anagrams, finding the first non-repeating character, checking if a string can be rearranged, and validating character-level constraints.

Explanation

Character hashing is a family of problems, not a single problem. What unifies them is the Phase 1 structure (identical across all problems) and what differentiates them is the Phase 2 retrieval (unique to each problem). Mastering character hashing means recognizing which problems share Phase 1 and knowing how Phase 2 varies.

How It Works

Read the problem: does it involve counting character occurrences?
If yes, Phase 1 is mechanical — build the frequency structure
Determine the Phase 2 pattern:
- Max/Min: traverse structure, track extreme value
- Order-sensitive: re-traverse the original string
- Comparison: build two structures and compare
- Constraint check: verify counts satisfy a condition (e.g., palindrome rearrangement: at most one odd count)
Apply the pattern to the specific problem

Visual Explanation

Semantic Network

Key Properties

All use cases share Phase 1 — the structure-building code is reusable across problems
Phase 2 is problem-specific — changing the problem changes only the retrieval logic
Problems can be categorized by Phase 2 pattern: max/min, order-sensitive, comparison, constraint
The category determines data structure choice (array vs map may differ by use case)
Recognition of the pattern is the skill — once Phase 2 is categorized, coding is mechanical

Connections

Built from: Two-Phase Hashing Paradigm — the paradigm defines the structure of all these problems
Built from: Hashing Retrieval Phase — each use case is a specific Phase 2 strategy
Builds into: Array vs Hash Map Decision Framework — understanding use cases enables choosing the right tool
Contrasts with: Most Frequent Character — a specific instance of the max/min category
Contrasts with: Anagram Detection — a specific instance of the comparison category
Contrasts with: First Non-Repeating Character — a specific instance of the order-sensitive category

Edge Cases & Gotchas

Not all string problems are hashing problems — substring search, pattern matching, and edit distance use different techniques
Some problems can be solved in one pass (tracking max while building frequencies) — the two-phase model is conceptual, not always sequential
For palindrome rearrangement: the constraint is “at most one character has odd count” — this Phase 2 check is a simple filter
For “character that appears more than n/2 times” (majority element): Boyer-Moore voting is more efficient than hashing — recognizing when NOT to hash is also important
For problems with very large alphabets (Unicode), hashing is necessary but may benefit from specialized data structures (e.g., trie for prefix frequencies)

first-non-repeating-character

2026-07-05T00:00:00.000Z

Formal Definition

The first non-repeating character in a string is the character that appears exactly once and whose first occurrence has the smallest index in the original string. The hash-based solution uses Phase 1 to build frequencies, then re-traverses the original string in Phase 2 to find the first character with count 1.

$\text{first\_non\_repeat}(S) = S_i \text{ where } H[S_i] = 1 \text{ and } \forall j < i, H[S_j] \neq 1$

Explanation

This problem is the first place where Phase 2 differs meaningfully from “traverse the structure.” Instead of walking the frequency array, you walk the original string a second time and check each character’s frequency. This preserves insertion order, which the frequency structure does not. It teaches that Phase 2 can re-traverse the input, not just the structure.

How It Works

Phase 1: Build frequency array or hash map from the input string
Phase 2: Iterate through the original string character by character
For each character ch, check freq[ch - 'a'] == 1 or freq[ch] == 1
Return the first character where count equals 1
If no character has count 1, return a sentinel (e.g., '\0' or '$')

Visual Explanation

Semantic Network

Key Properties

O(n) Phase 1 + O(n) Phase 2 = O(n) total — two linear passes
Preserves original string order in Phase 2 — this is why re-traversal is necessary
The frequency structure alone cannot answer this question (it loses order information)
Works with both arrays and hash maps — Phase 2 checks are O(1) in both
Early termination possible — stop at the first match

Connections

Built from: Hashing Retrieval Phase — re-traversing input is a specific Phase 2 pattern
Built from: Two-Phase Hashing Paradigm — the canonical example of Phase 2 differing from Phase 1
Built from: Frequency Array — one implementation choice
Contrasts with: Most Frequent Character — same Phase 1, different Phase 2 strategy
Related: Anagram Detection — another Phase 2 variant
Related: Hash Map Traversal Method — re-traversal works regardless of structure type

Edge Cases & Gotchas

All characters are repeating (e.g., “aabbcc”): no character has count 1 — must handle the no-solution case
Empty string: return sentinel immediately
Single character (e.g., “z”): that character is the answer — Phase 2 finds it on the first check
Case sensitivity: ‘A’ and ‘a’ are different characters — the hash structure treats them separately
For strings with only one unique character appearing once (e.g., “aaaabbbbccccd”): ‘d’ is the answer
The naive solution without hashing is O(n²) — the hash structure reduces this to O(n)

Frequency Array vs Hash Map — Character Hashing Tradeoffs

2026-07-05T00:00:00.000Z

Framing

When solving character frequency problems, the first implementation decision is: frequency array (int freq[26]) or hash map (unordered_map<char,int>)? Both are O(1) for access, both solve the same Phase 1 problem, but they differ significantly in performance, memory, flexibility, and determinism. This synthesis compares them across the dimensions that matter in coding interviews and competitive programming.

Comparison

Dimension	Frequency Array	Hash Map
Access time	True O(1) — single CPU instruction	Average O(1) — hash + possible chain walk
Worst-case	O(1) always	O(n) with hash collisions
Memory	Fixed O(\|Σ\|) — e.g., 104 bytes for 26 ints	O(m) where m = distinct keys, but higher per-entry overhead
Character range	Must be known and small (e.g., a–z)	Any hashable type — char, string, int, custom
ASCII math	Requires `ch - 'a'` and `i + 'a'`	None — direct key usage
Iteration order	Deterministic (0–25 index order)	Non-deterministic (bucket layout)
Sparse data	Wastes iteration over empty slots	Only visits present entries
Stack vs heap	Stack allocation (fast, no fragmentation)	Heap allocation (slower, may fragment)
Implementation complexity	Trivial — 1 line declaration	Slightly more — need `#include <unordered_map>`
Rehashing	Never	Amortized O(n) when load factor exceeded

When to Choose Each

Choose frequency array when:

The problem guarantees a limited character set (e.g., “string of lowercase letters”)
Maximum performance is required (time-critical section, embedded systems)
Deterministic output order is needed (alphabetical by default)
Memory is constrained and the domain is small

Choose hash map when:

The character set is unknown or mixed (uppercase, digits, symbols)
Keys are not characters (word frequencies, integer frequencies)
The input is sparse over a large domain (better memory for few distinct keys)
The problem involves Unicode or extended character sets

Insights Beyond Individual Concepts

The array-vs-map choice reveals a deeper principle in software engineering: the best data structure depends on the constraints of the problem, not on abstract asymptotic analysis. Both are “O(1)” but the constants differ by orders of magnitude. A naive preference for maps (because they are more flexible) misses the performance advantage of arrays, and a naive preference for arrays (because they are faster) misses the flexibility advantage of maps.

The interview answer that demonstrates mastery is the conditional one: “It depends on the character range.” This shows the candidate understands the tradeoffs rather than having memorized a rule.

Connections

Frequency Array — the array-based approach, fastest for known domains
Unordered Map for Frequency Counting — the map-based approach, most flexible
Known Range Assumption — the precondition that makes arrays viable
Hash Map Flexibility — the key advantage of maps
Memory Efficiency of Frequency Array — why arrays use less memory
Direct Array Access — why arrays are faster at the hardware level
Hash Collision Overhead — the hidden cost of maps
ASCII Math Elimination — one of the ergonomic benefits of maps
Unordered Map Non-Determinism — the ordering tradeoff of maps
Array vs Hash Map Decision Framework — the practical decision process

hash-map-flexibility

2026-07-05T00:00:00.000Z

Formal Definition

Hash map flexibility refers to the ability of std::unordered_map (and similar hash-based associative containers) to accept any hashable type as a key — including char, int, string, long long, and custom types with a user-provided hash function. This contrasts with frequency arrays, which are limited to integer-indexable domains.

Explanation

A frequency array is hardcoded to a specific domain: int freq[26] works only for 26 lowercase letters. A hash map, by contrast, works for any type that has a hash function. Need to count word frequencies? unordered_map<string, int>. Need to count frequencies of long long IDs? unordered_map<long long, int>. The same data structure and the same freq[key]++ pattern works across all key types.

How It Works

C++ std::unordered_map uses std::hash<Key> to compute a size_t hash value for any key
The C++ standard library provides specializations of std::hash for all fundamental types
At insertion, the key is stored alongside the value in the bucket
On lookup, the key is hashed again, and the bucket chain is compared using operator==
For custom types, the programmer provides a std::hash specialization

Visual Explanation

Semantic Network

Key Properties

Works with any hashable type: char, int, string, long long, pointers, custom structs
No compile-time domain constraint — the key type is a template parameter, not a fixed size
Same code pattern (freq[key]++) regardless of key type
Custom types require a custom hash function and operator==
The flexibility comes at a cost: hash computation, dynamic memory allocation, pointer indirection

Connections

Built from: Hash Collision Overhead — flexibility requires hash functions, which can collide
Builds into: Unordered Map for Frequency Counting — maps are the concrete implementation
Builds into: ASCII Math Elimination — flexibility enables direct key usage
Contrasts with: Known Range Assumption — arrays sacrifice flexibility for the assumption
Contrasts with: Memory Efficiency of Array — flexibility costs memory

Edge Cases & Gotchas

std::unordered_map has no default hash for custom types — the compiler error is cryptic (“cannot convert from T to size_t”)
For string keys, the hash function iterates the entire string — O(len(key)) per hash, not just O(1)
Floating-point keys are problematic: NaN != NaN per IEEE 754, so lookup fails
Pointer keys hash by address, not by value — two different pointers with the same value are different keys
The flexibility argument cuts both ways: too flexible means type errors surface at runtime or as linker errors

interview-decision-framework

2026-07-05T00:00:00.000Z

Formal Definition

The array vs hash map decision framework is the process of choosing between int freq[26] and unordered_map<char,int> for character frequency problems based on three factors: the character range (known and small vs unknown or large), the performance requirements (speed vs flexibility), and the memory constraints (fixed vs dynamic).

Explanation

When an interviewer asks “array or unordered_map?” the strong answer is not a dogmatic preference but a conditional analysis: “If the character range is fixed and small (a–z), I would use a frequency array because it is faster and uses less memory. If the range is large or unknown, I would use unordered_map because it is more flexible.” This shows understanding of the tradeoffs rather than memorization.

How It Works

Check the range: ask if the string is guaranteed lowercase letters
If small and known (a–z, A–Z, digits): use int freq[N] — faster, simpler, deterministic
If large or unknown (Unicode, mixed, any char): use unordered_map — flexible, no ASCII math
If ordered output required: use array (sorted by index) or std::map (tree-based order)
If memory-constrained with sparse input: consider map (stores only what appears)

Visual Explanation

digraph decision_framework {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
 
  RANGE [label="Character range\nknown and small?" shape=diamond]
  ARR_PATH [label="Use Frequency Array\nint freq[26]\nFast, deterministic\nLow memory", fillcolor="#d4edda"]
  MAP_PATH [label="Use Hash Map\nunordered_map<char,int>\nFlexible, no ASCII math", fillcolor="#cce5ff"]
  ORDER [label="Ordered output\nneeded?" shape=diamond]
  ORDER_ARR [label="Array (index-order) or\nstd::map (key-order)" fillcolor="#ffe5cc]
 
  RANGE -> ARR_PATH [label="yes\n(a-z)"]
  RANGE -> MAP_PATH [label="no\n(unknown)"]
  ARR_PATH -> ORDER [label="optional"]
  MAP_PATH -> ORDER [style=dashed]
  ORDER -> ORDER_ARR [label="yes"]
}

Semantic Network

Key Properties

Range, speed, memory, and determinism are the four decision axes
No universal “better” choice — the decision depends on the problem constraints
Interviewers look for conditional reasoning, not a fixed preference
The answer should be conversational: “Generally I’d use X, but if Y then Z”
The framework applies beyond character hashing — it generalizes to any array-vs-hash decision

Connections

Built from: Known Range Assumption — the range check is the first decision step
Built from: Memory Efficiency of Array — memory is a decision factor
Built from: Hash Map Flexibility — flexibility is the deciding factor for unknown ranges
Builds into: Character Hashing Use Cases — the framework applies to every use case
Contrasts with: Hash Collision Overhead — maps pay a collision cost that arrays avoid
Related: ASCII Math Elimination — one reason to choose maps

Edge Cases & Gotchas

“I always use unordered_map because it’s O(1)” is a naive answer — interviewers see it as a red flag (ignores constant factors)
“I always use arrays because they’re faster” misses the flexibility argument — it fails for mixed character sets
The “hash map is O(1)” claim is average-case, not worst-case — a good candidate mentions this nuance
For strings with only a few characters (n < 10), the overhead of any data structure may dominate — a simple loop without hashing could be faster
The framework assumes you need to solve a frequency problem — if the problem doesn’t require frequencies (e.g., simple character presence check), a std::set or bool array is more appropriate

known-range-assumption

2026-07-05T00:00:00.000Z

Formal Definition

The known range assumption states that a frequency array is only viable when the set of possible keys is known, finite, and can be mapped to contiguous integer indices. For character hashing, this means the alphabet must be predetermined (e.g., ‘a’–‘z’, ‘A’–‘Z’, or ASCII 0–127). When this assumption breaks, hash maps become necessary.

Explanation

A frequency array of size 26 works perfectly for lowercase English letters because there are exactly 26 of them and they are contiguous in ASCII. But the moment you encounter a ’#’, ‘1’, ‘A’ (uppercase), or any Unicode character, the array approach fails — either the character doesn’t fit in 26 slots, or the mapping ch - 'a' produces nonsense. The known range assumption is the invisible precondition that makes frequency arrays work, and its violation is the primary reason to switch to hash maps.

How It Works

Determine the domain: what characters could possibly appear in the input?
If the domain is small and contiguous (26 lowercase letters): array works
If the domain is small but non-contiguous (e.g., digits + letters): array needs careful mapping
If the domain is large or unknown: array is impractical or impossible
The assumption is checked at problem analysis time, not at runtime

Visual Explanation

digraph known_range {
  rankdir=TB
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
 
  CHECK [label="What characters can appear?" shape=diamond]
  LOW [label="Only a-z\nArray size=26\nDirect mapping"]
  MIXED [label="Mixed case +\npunctuation\nArray impractical" fillcolor="#ffe5cc]
  UNICODE [label="Unicode / unknown\nArray impossible\nUse hash map" fillcolor="#ffe5cc]
  PASS [label="Use freq[26]" fillcolor="#d4edda"]
  FAIL1 [label="Use unordered_map" fillcolor="#d4edda"]
 
  CHECK -> LOW [label="letters only"]
  CHECK -> MIXED [label="multiple types"]
  CHECK -> UNICODE [label="any character"]
  LOW -> PASS
  MIXED -> FAIL1
  UNICODE -> FAIL1
}

Semantic Network

Key Properties

The most commonly violated assumption in coding interviews — candidates use freq[26] without checking the character set
When violated, the fix is to switch to a hash map (or expand the array to cover the full ASCII range, e.g., int freq[256])
The assumption is implicit in the problem statement — “given a string of lowercase letters” explicitly guarantees it
For competitive programming, problems often specify the character set to allow array-based solutions
Extending the array to int freq[256] covers standard ASCII but not Unicode

Connections

Built from: Character-to-Index Mapping — mapping is only valid when the range is known
Builds into: Frequency Array — arrays depend on this assumption being true
Builds into: Array vs Hash Map Decision Framework — this assumption is the deciding factor
Contrasts with: Hash Map Flexibility — hash maps do not require this assumption
Related: ASCII Math Elimination — both are reasons to prefer maps over arrays

Edge Cases & Gotchas

“String of lowercase letters” guarantees the assumption — freq[26] is correct
“String of characters” without qualification does NOT — use a hash map or ask for clarification
Extended ASCII (128–255) breaks int freq[256] if char is signed (values become negative)
Unicode characters may be multi-byte in C++ — neither freq[26] nor unordered_map<char,int> handles this correctly; use unordered_map<string,int> for UTF-8 strings
The assumption can be partially satisfied with a translation table (mapping arbitrary characters to dense indices), but this is rarely worth the complexity

map-traversal-method

2026-07-05T00:00:00.000Z

Formal Definition

Hash map traversal is the process of iterating over all key-value pairs stored in an unordered_map. In C++, this is done via range-based for loops over the map, where each element is a std::pair<const Key, Value>. Unlike array traversal which iterates a fixed range (0–25), map traversal visits only the actually inserted entries, in unspecified order.

Explanation

When traversing a frequency array, you loop i = 0 to 25 and check if freq[i] > 0. This visits every slot, including empty ones. When traversing a hash map, you iterate over the stored key-value pairs directly — only the characters that actually appeared. This is more efficient for sparse data but introduces non-deterministic ordering.

How It Works

Obtain an iterator or range: for(auto& pair : freq)
Each pair has .first (the key) and .second (the value)
Process pair.first and pair.second as needed
The iteration visits every stored entry exactly once
Order is determined by internal bucket layout, not by key order

Visual Explanation

Semantic Network

Key Properties

Only visits entries that actually exist — no wasted iterations over empty slots
Time complexity O(m) where m is distinct characters (not domain size |Σ|)
No index-to-character conversion needed — the key is already the character
Iteration order is unspecified and non-deterministic — do not rely on it
For output, results may appear in different order across runs

Connections

Built from: Unordered Map for Frequency Counting — traversal is the retrieval method for maps
Builds into: Hashing Retrieval Phase — maps have their own traversal pattern in Phase 2
Contrasts with: Index-to-Character Conversion — maps don’t need conversion; arrays do
Contrasts with: Frequency Array — arrays iterate 0–25; maps iterate stored entries only
Related: Unordered Map Non-Determinism — traversal order is unpredictable

Edge Cases & Gotchas

For maps with many entries, iteration order changes after rehashing (when load factor exceeds threshold)
Do NOT modify the map while iterating (adding/removing entries) — this causes undefined behavior
Using auto instead of auto& copies each pair — O(n) extra work for large maps
For ordered output, copy to a vector and sort, or use std::map (which has O(log n) operations)
The loop variable .first and .second can be confusing to beginners — use structured bindings: auto& [key, value] : freq

memory-efficiency-array

2026-07-05T00:00:00.000Z

Formal Definition

A frequency array has memory proportional to the domain size ( $O(|\Sigma|)$ ) regardless of the input size, with zero per-entry overhead beyond the integer storage itself. For lowercase letters, int freq[26] occupies exactly $26 \times 4 = 104$ bytes — a fixed cost that does not grow with the string length.

Explanation

The memory efficiency of a frequency array comes from two properties: it is a fixed-size allocation determined at compile time, and it stores data in a contiguous block with no per-element metadata, no hash table buckets, no linked list pointers, and no key duplication. A hash map, by contrast, stores the key alongside each value, plus internal hash table structures. For small domains, the array’s memory advantage is significant.

How It Works

int freq[26] allocates 26 × sizeof(int) bytes on the stack (or in static memory)
Each slot is accessed via base+offset addressing — no pointers, no indirection
The entire array fits in a single CPU cache line (typically 64 bytes × 2 for 104 bytes)
No memory is wasted on empty slots — every slot is exactly sized for one integer
No heap allocation, no reallocation, no memory fragmentation

Mathematical Formulation

$\text{Memory}_{\text{array}} = |\Sigma| \times \text{sizeof}(\text{element})$

$\text{Memory}_{\text{array}}(26) = 26 \times 4 = 104 \text{ bytes}$

$\text{Memory}_{\text{map}} = m \times (\text{sizeof}(\text{key}) + \text{sizeof}(\text{value}) + \text{overhead})$

where $m$ is the number of distinct characters and overhead includes hash table bucket, pointer chain, and alignment padding.

Visual Explanation

Semantic Network

Key Properties

Fixed 104 bytes for lowercase English — independent of string length
Zero per-entry overhead — just the integer value itself
Stack allocation — no heap fragmentation, no pointer chasing
Cache-friendly — sequential access pattern leverages spatial locality
Hash maps typically use 3–5× more memory per entry due to key storage, bucket array, and pointer chains

Connections

Built from: Direct Array Access — contiguous memory enables efficient addressing
Builds into: Frequency Array — memory efficiency is a key advantage of arrays
Builds into: Array vs Hash Map Decision Framework — memory is a decision factor
Contrasts with: Hash Collision Overhead — maps pay for collision resolution structures
Contrasts with: Hash Map Flexibility — flexibility comes with memory cost

Edge Cases & Gotchas

For very large alphabets (e.g., Unicode with 1M+ code points), the array becomes impractical — int freq[1,114,112] is over 4 MB
Stack allocation for large arrays causes stack overflow — use heap allocation (std::vector) instead
If only 3 out of 26 characters appear, the array still uses all 104 bytes — no savings from sparsity
The memory advantage reverses for sparse data over a large domain: a hash map storing only the 3 appearing characters uses less memory than a full array of the domain
For multibyte encodings (UTF-8), neither freq[26] nor a simple char map works — the key type must handle variable-length sequences

most-frequent-character

2026-07-05T00:00:00.000Z

Formal Definition

Finding the most frequent character in a string using hashing means traversing the frequency structure (array or hash map) after Phase 1 to identify the key-value pair with the maximum count. For ties, any character with the maximum count is acceptable unless otherwise specified.

$\text{most\_frequent}(S) = \arg\max_{c \in \text{keys}(H)} H[c]$

where $H$ is the hash structure built in Phase 1.

Explanation

After building a frequency array or hash map, the data is stored but not interpreted. Finding the most frequent character is the simplest Phase 2 operation: walk through every entry in the structure, compare counts, and track the current maximum. This teaches the core pattern that Phase 1 is mechanical and Phase 2 is analytical.

How It Works

Complete Phase 1 — build int freq[26] or unordered_map<char,int> freq
Initialize tracking variables: char maxChar = ' ', int maxCount = 0
Traverse the frequency structure:
- For array: loop i = 0 to 25, if freq[i] > maxCount, update maxCount = freq[i], maxChar = i + 'a'
- For map: iterate key-value pairs, if pair.second > maxCount, update
After traversal, maxChar holds the most frequent character

Visual Explanation

Semantic Network

Mathematical Formulation

Given hash structure $H: \text{Key} \to \mathbb{N}$ :

$\text{result} = \max_{(k,v) \in H} v$

$\text{character} = k \text{ where } (k, \max) \in H$

Key Properties

O(n) Phase 1 (traverse string) + O(|Σ|) or O(m) Phase 2 (traverse structure) = overall O(n)
Only a constant amount of extra space needed (two tracking variables)
Works identically for both frequency arrays and hash maps
For ties, returns the first maximum encountered — order-dependent
Cannot be solved correctly without Phase 1 — the hash structure is essential

Connections

Built from: Hashing Retrieval Phase — traversing structure for max is a Phase 2 pattern
Built from: Two-Phase Hashing Paradigm — follows the store-then-query pattern
Built from: Frequency Array — one implementation choice for Phase 1
Builds into: Character Hashing Use Cases — a canonical example problem
Contrasts with: First Non-Repeating Character — same Phase 1, different Phase 2 traversal
Related: Index-to-Character Conversion — needed to convert the max index back to a character

Edge Cases & Gotchas

Empty string: Phase 1 produces an empty structure — handle separately or initialize maxCount to 0 and return a sentinel
Ties: the problem may expect any character — clarify with the interviewer whether the first, last, or lexicographically smallest should be returned
Single character string: the answer is that character — works correctly in both structures
All characters appear once: the first character in traversal order wins (for maps, this is non-deterministic)
For hash maps, if tied characters exist, the result depends on internal bucket order — non-deterministic across runs

Strings — Map of Content

2026-07-05T00:00:00.000Z

Map of Content for all pages derived from Strings (Character Hashing in C++).

Core Paradigm

Two-Phase Hashing Paradigm — the fundamental model
Hashing Store Phase (Phase 1) — building the frequency structure
Hashing Retrieval Phase (Phase 2) — querying the structure

Data Structures

Frequency Array — fixed-size array for known domains
Unordered Map for Frequency Counting — hash map for flexible domains
Direct Array Access — hardware-level O(1) array indexing
Hash Collision Overhead — performance cost of hash maps

Mappings & Conversions

Character-to-Index Mapping — ch - 'a'
Index-to-Character Conversion — i + 'a'
ASCII Math Elimination — maps remove the need for ASCII math

Key Properties & Assumptions

Known Range Assumption — when arrays work
Memory Efficiency of Frequency Array — fixed 104-byte footprint
Hash Map Flexibility — any hashable key type
Hash Map Traversal Method — iterating key-value pairs
Unordered Map Non-Determinism — unspecified iteration order

Problem Patterns (Phase 2)

Most Frequent Character via Hashing — traverse for max
First Non-Repeating Character via Hashing — re-traverse input
Anagram Detection via Hashing — compare two structures
Character Hashing Use Cases — catalog of all patterns

Decision Making

Array vs Hash Map Decision Framework — choosing the right tool
Frequency Array vs Hash Map — detailed comparison
Two-Phase Hashing Patterns — catalog of Phase 2 strategies

Two-Phase Hashing Patterns — A Catalog of Phase 2 Strategies

2026-07-05T00:00:00.000Z

Framing

The two-phase hashing paradigm separates frequency problems into Phase 1 (store) and Phase 2 (use). While Phase 1 is nearly identical across all problems, Phase 2 varies based on what the problem asks for. This deep-dive catalogs the distinct Phase 2 patterns, showing how the same data structure supports fundamentally different queries.

The Five Phase 2 Patterns

Pattern 1: Traverse for Extremum (Most Frequent Character)

Walk the entire structure, tracking a running maximum. For arrays, this means iterating indices 0–25. For maps, iterating key-value pairs.

maxCount = 0
maxChar = ''
for each entry (key, count) in structure:
    if count > maxCount:
        maxCount = count
        maxChar = key
return maxChar

Used by: most frequent character, least frequent character, character with maximum occurrences

Pattern 2: Re-traverse Input for Order (First Non-Repeating Character)

Iterate the original string a second time and check each character’s frequency in the structure. This preserves the original insertion order.

for each ch in originalString:
    if freq[ch] == 1:
        return ch
return sentinel

Used by: first non-repeating character, first repeating character, first character with frequency K

Pattern 3: Compare Two Structures (Anagram Detection)

Build two frequency structures (Phase 1 for each input), then compare entry by entry. For arrays this means element-wise comparison; for maps, checking all key-value pairs match.

if len(S1) != len(S2): return false
freq1 = build(S1)
freq2 = build(S2)
return freq1 == freq2

Used by: anagram detection, string permutation check, isomorphic strings

Pattern 4: Constraint Check (Palindrome Rearrangement)

Check if frequencies satisfy a condition without finding a specific character. The condition often involves the parity of counts.

oddCount = 0
for each count:
    if count % 2 == 1:
        oddCount++
return oddCount <= 1

Used by: palindrome rearrangement possible? string can be made palindrome, at most K swaps

Pattern 5: Structure Comparison with Difference (Edit Distance for Anagrams)

Compute the difference between two frequency structures to determine how many changes are needed to make two strings anagrams.

diff = 0
for i in 0..25:
    diff += abs(freq1[i] - freq2[i])
return diff / 2

Used by: minimum steps to make anagram, character deletions to make strings equal

Insights

The key insight is that Phase 1 is invariant across all these problems. You can write the frequency-building code once and reuse it. The only thing that changes is the Phase 2 loop. This is why recognizing the pattern is more important than memorizing the solution: once you identify which Phase 2 pattern a problem uses, you can write the solution from first principles.

A second insight is that some problems combine multiple patterns. For example, finding the most frequent character in the first string that also appears at least twice in the second string: Pattern 3 (compare) + Pattern 1 (extremum).

Connections

Two-Phase Hashing Paradigm — the overarching model
Hashing Store Phase — Phase 1, invariant across patterns
Hashing Retrieval Phase — Phase 2, the pattern catalog
Most Frequent Character — implements Pattern 1
First Non-Repeating Character — implements Pattern 2
Anagram Detection — implements Pattern 3
Character Hashing Use Cases — the full set of problems
Frequency Array — the structure used in Phase 1
Unordered Map for Frequency Counting — alternative Phase 1 structure

unordered-map-non-determinism

2026-07-05T00:00:00.000Z

Formal Definition

Unordered map non-determinism refers to the property that std::unordered_map does not guarantee any specific iteration order, and the order may change between program runs, library versions, or after rehashing. The iteration order is determined by the internal bucket layout, which depends on the hash function, load factor, and insertion history.

Explanation

When you iterate a frequency array (0–25), the order is always a, b, c, …, z. When you iterate an unordered_map<char, int>, the order depends on how the hash function distributes keys across buckets. For “banana”, you might get {a:3, b:1, n:2} in one run and {b:1, n:2, a:3} in another. This matters when output order is part of the problem specification or test cases.

How It Works

Each key is hashed to a bucket index: bucket = hash(key) % bucket_count
Insertion order within a bucket is the order of insertion into that bucket’s chain
Iteration visits buckets in order of bucket index, then entries within each bucket
When the map rehashes (grows), all entries are rehashed — bucket assignments change
The hash function may use a random seed (SSO/ASLR) to prevent hash DoS attacks, making order vary across executions

Visual Explanation

digraph non_determinism {
  rankdir=LR
  node [shape=box style=filled fillcolor="#f0f4ff" fontname="Helvetica"]
 
  SRC [label="Source:\n{a:3, b:1, n:2}"]
  RUN1 [label="Run 1:\na=3, b=1, n=2"]
  RUN2 [label="Run 2:\nb=1, n=2, a=3" fillcolor="#ffe5cc]
  RUN3 [label="Run 3:\nn=2, a=3, b=1" fillcolor="#ffe5cc]
 
  SRC -> RUN1
  SRC -> RUN2
  SRC -> RUN3
}

Semantic Network

graph semantic_non_determinism {
  layout=neato
  node [shape=ellipse fontname="Helvetica" fontsize=11 style=filled]
  edge [fontname="Helvetica" fontsize=9]
 
  THIS [label="Unordered Map Non-Determinism" fillcolor="#ffd700" fontsize=13 style="filled,bold"]
  PRE1 [label="Hash Collision Overhead" fillcolor="#cce5ff"]
  PRE2 [label="Hash Map Flexibility" fillcolor="#cce5ff"]
  OUT1 [label="Map Traversal Method" fillcolor="#d4edda]
  CON1 [label="Frequency Array" fillcolor="#ffe5cc"]
  REL1 [label="Interview Decision Framework" fillcolor="#f0f0f0"]
  REL2 [label="Array vs Hash Map Tradeoffs" fillcolor="#f0f0f0"]
 
  THIS -- PRE1 [label="built from" style=dashed]
  THIS -- PRE2 [label="built from" style=dashed]
  THIS -- OUT1 [label="builds into"]
  THIS -- CON1 [label="contrasts with" style=dotted]
  THIS -- REL1 [label="related"]
  THIS -- REL2 [label="related"]
}

Key Properties

Iteration order is not a bug — it is a design feature (performance over determinism)
Order can change between: compilers, standard library versions, program runs, and before/after rehashing
Frequency arrays guarantee deterministic, sorted-by-index order
If order matters, copy to a vector and sort, or use std::map (tree-based, ordered)
Non-determinism affects output formatting, not correctness of frequency values

Connections

Built from: Hash Collision Overhead — bucket layout drives iteration order
Built from: Hash Map Flexibility — the flexibility tradeoff includes non-determinism
Builds into: Hash Map Traversal Method — traversal must account for unspecified order
Contrasts with: Frequency Array — arrays give predictable, index-based order
Related: Array vs Hash Map Decision Framework — determinism is a decision factor

Edge Cases & Gotchas

Automated test suites that compare output as strings will fail if they expect a specific order from unordered_map
Using std::map instead guarantees order but costs O(log n) per operation — not always necessary
For “first non-repeating character” problems, re-traversing the original string (not the map) avoids the ordering issue entirely
If the problem says “print frequencies in any order,” unordered_map is fine; if it says “print in alphabetical order,” use an array or a sorted container
The non-determinism is a concern for reproducibility in debugging — a bug that depends on iteration order may not reproduce consistently

character-to-index-mapping

2026-07-03T00:00:00.000Z

Formal Definition

Character-to-index mapping is the transformation of a character to an integer index by subtracting the base character’s ASCII value. For lowercase English letters, index = ch - 'a' maps ‘a’→0, ‘b’→1, …, ‘z’→25. This enables using characters as array indices.

$\text{index}(c) = \text{ASCII}(c) - \text{ASCII}(\text{base})$

Explanation

Computers store characters as integer codes (ASCII, UTF-8). When characters are contiguous in the encoding — as lowercase letters ‘a’–‘z’ are — subtracting the base character’s code produces a zero-based index. This is the bridge between the character domain and the array-index domain, and it is what makes frequency arrays possible.

How It Works

Determine the base character (e.g., ‘a’ for lowercase letters, ‘A’ for uppercase)
Get the ASCII value of the target character: int(ch)
Subtract the ASCII value of the base character: int(ch) - int('a')
The result is a zero-based index suitable for array access

For 'a' through 'z', ASCII values are 97–122, so ch - 'a' yields 0–25.

Mathematical Formulation

Given ASCII encoding where $\text{ASCII}('a') = 97$ :

$\text{idx}(c) = \text{code}(c) - \text{code}('a')$

$\text{idx}(c) \in \{0, 1, 2, \dots, 25\} \quad \text{for } c \in \{'a', 'b', \dots, 'z'\}$

Visual Explanation

Semantic Network

Key Properties

O(1) computation — simple integer subtraction
Requires characters to be contiguous in the encoding
Only works for a single case at a time (lowercase or uppercase, not both)
Assumes ASCII encoding (works in C++ on all major platforms)
The inverse operation is i + 'a'

Connections

Built from: Direct Array Access — relies on ASCII values being contiguous integers
Builds into: Frequency Array — the mapping is required to index the frequency array
Builds into: Index-to-Character Conversion — the mathematical inverse operation
Contrasts with: ASCII Math Elimination — hash maps remove the need for this conversion entirely
Related: Known Range Assumption — only works when character range is known and contiguous

Edge Cases & Gotchas

Applying ch - 'a' to an uppercase character ‘A’–‘Z’ (ASCII 65–90) gives negative indices — undefined behavior
Applying it to digits, punctuation, or spaces gives unpredictable indices
Mixing cases silently produces wrong results — ‘A’ maps to -32 (wraps around for unsigned, negative for signed)
C++ char may be signed or unsigned depending on platform — ch - 'a' with negative char values is implementation-defined
The mapping assumes ASCII; EBCDIC systems do not have contiguous letters

direct-array-access

2026-07-03T00:00:00.000Z

Formal Definition

Direct array access is memory access via base-pointer-plus-offset addressing with no indirection, hashing, or collision resolution. Given a contiguous array and a valid index, the hardware computes the address in a single instruction: address = base + index * element_size. This is the fastest possible random-access lookup.

Explanation

When you write freq[3], the CPU computes address_of_freq + 3 * sizeof(int) and fetches the value. No hash function computation, no bucket traversal, no collision chains to follow. For character frequency problems with a small known domain, this makes arrays strictly faster than hash maps despite both being theoretically O(1).

How It Works

The array is allocated as a contiguous block of memory
The compiler knows the base address and element size
At runtime, freq[i] compiles to a single MOV instruction with scaled index addressing
The memory access is predictable — adjacent elements are in adjacent memory locations (spatial locality)
No branching, no function calls, no hash computation

Visual Explanation

Semantic Network

Key Properties

True hardware-level O(1) — single CPU instruction
No hashing, no collisions, no amortization, no worst-case degradation
Perfect spatial locality — sequential access is cache-friendly
Indices must be valid (0 to size-1) — no bounds checking by default in C++
Works only for contiguous, densely populated index ranges

Connections

Built from: Character-to-Index Mapping — direct access requires valid indices via conversion
Builds into: Frequency Array — direct access is the fundamental advantage of arrays
Builds into: Memory Efficiency of Array — minimal overhead per slot enables cache efficiency
Contrasts with: Hash Collision Overhead — hash maps trade direct access for flexibility
Related: Known Range Assumption — direct access requires known, bounded ranges

Edge Cases & Gotchas

Out-of-bounds access leads to undefined behavior (silent memory corruption)
C++ does not bounds-check array accesses — use std::array or at() for safety
For negative indices (from incorrect ch - 'a' on uppercase), the behavior is undefined
Cache misses can still occur for very large arrays (but for freq[26], the entire array fits in a single cache line)
Direct access assumes contiguous allocation — vectors also provide this, but with heap allocation overhead

frequency-array

2026-07-03T00:00:00.000Z

Formal Definition

A frequency array is a fixed-size integer array where each index represents a distinct element from a known, finite domain, and the value at that index stores the count of occurrences of that element in a given dataset. For lowercase English letters, int freq[26] uses indices 0–25 to represent ‘a’–‘z’.

$\text{freq}[i] = \text{count of character } (i + \text{'a'}) \text{ in the input string}$

Explanation

A frequency array is the simplest possible hash-like structure: instead of hashing keys, you use the key itself (after a trivial transformation) as the array index. When the domain is small and known (like 26 lowercase letters), this gives you O(1) access with zero hashing overhead, zero collision handling, and minimal memory. It is the go-to data structure for character frequency problems in competitive programming and technical interviews.

How It Works

Declare an array of size equal to the domain size (e.g., int freq[26] = {0} for lowercase letters)
Iterate through the input string character by character
Convert each character to its corresponding index using ch - 'a'
Increment freq[index] for each occurrence
To query, iterate indices 0 through size-1 and check non-zero values

Mathematical Formulation

For a string $S$ of length $n$ over alphabet $\Sigma$ where $|\Sigma| = k$ :

$\text{freq}[j] = \sum_{i=1}^{n} [S_i = \sigma_j]$

where $[P]$ is the Iverson bracket (1 if $P$ true, 0 otherwise) and $\sigma_j$ is the $j$ -th character of the alphabet.

Visual Explanation

Semantic Network

Key Properties

O(1) time for both insertion and lookup — true constant time, no amortization
Memory proportional to domain size ( $O(|\Sigma|)$ ), not input size ( $O(n)$ )
Zero hashing overhead — no hash function computation, no collision resolution
Only works when the domain is known, finite, and contiguous (or near-contiguous)
Access pattern is predictable — sequential memory access when iterating

Connections

Built from: Character-to-Index Mapping — the ch - 'a' conversion is required to map characters to array indices
Builds into: Two-Phase Hashing — frequency arrays are the storage mechanism in Phase 1
Builds into: Most Frequent Character — traversing the array finds the max frequency
Builds into: Anagram Detection — comparing two frequency arrays checks anagrams
Contrasts with: Unordered Map for Frequency — maps offer flexibility but with hashing overhead
Related: Direct Array Access — no hashing means truly direct memory access

Edge Cases & Gotchas

Forgetting to zero-initialize the array (int freq[26] = {0}) leads to garbage values
Using ch - 'a' on uppercase letters or non-alphabetic characters produces negative indices or out-of-bounds access
Array size must match the domain — freq[26] fails for extended ASCII or Unicode
Iterating all 26 slots when only 3 characters appeared wastes time (minor but relevant for sparse data)
The array stores frequencies, not positions — cannot directly answer “where does character X first appear?”

hash-collision-overhead

2026-07-03T00:00:00.000Z

Formal Definition

Hash collision overhead is the performance penalty incurred when two distinct keys hash to the same bucket in a hash table, requiring additional comparisons to resolve the collision. In std::unordered_map, collisions are resolved via chaining (linked lists), making lookup O(k) where k is the bucket chain length.

Explanation

When you claim unordered_map offers O(1) access, the fine print is “average O(1) assuming a good hash function.” Collisions occur when different characters produce the same hash bucket. The map must then walk a linked list of entries to find the right one. In the worst case (all keys colliding), lookup degrades to O(n). A frequency array never has this problem because array indexing is collision-free by design.

How It Works

When inserting freq[ch], the map computes hash(ch) % bucket_count
If the bucket is empty, the entry is placed directly
If the bucket already has entries (collision), the new entry is appended to the chain
On lookup, the map hashes the key, goes to the bucket, and walks the chain comparing keys
With a good hash function and adequate bucket count, chain length averages O(1)

Visual Explanation

Semantic Network

Key Properties

Average-case O(1) degrades to worst-case O(n) with poor hash distribution
Frequency arrays have zero collision overhead — index can only map to one location
C++ std::unordered_map uses chaining, so collisions add pointer indirection
Rehashing (when load factor exceeds threshold) is O(n) — a costly amortized operation
For small character sets (26 letters), maps are overkill and collisions are wasted work

Connections

Built from: Direct Array Access — arrays bypass the collision problem entirely
Builds into: Unordered Map for Frequency — collision handling is part of the map’s implementation cost
Builds into: Hash Map Flexibility — collision overhead is the cost of hash map flexibility
Contrasts with: Memory Efficiency of Array — arrays have predictable, linear memory with no overhead
Related: Unordered Map Non-Determinism — collision resolution affects iteration order

Edge Cases & Gotchas

For character keys, C++‘s default hash for char is usually good — collisions are rare but possible
String keys (for word frequency) have a higher collision probability than single chars
A maliciously crafted input can trigger many collisions, causing O(n²) behavior — hash DoS attack
The “average O(1)” claim assumes the hash function is well-distributed — never guaranteed for arbitrary keys
Rehashing invalidates all iterators — a subtle bug when interleaving Phase 1 traversal with Phase 2

hashing-retrieval-phase

2026-07-03T00:00:00.000Z

Formal Definition

The hashing retrieval phase (Phase 2) is the process of querying the hash structure built in Phase 1 to produce the answer to a specific problem. The retrieval strategy varies by problem — traversing the structure, re-traversing the input, or comparing multiple structures.

Explanation

Phase 2 is where the actual problem-solving happens. While Phase 1 is nearly identical across all frequency-counting problems, Phase 2 diverges dramatically. For “most frequent character” you traverse the structure tracking a max variable. For “first non-repeating” you re-traverse the original string. For “anagram” you compare two structures. Mastering Phase 2 is what separates strong candidates from beginners.

How It Works

Determine the query pattern based on the problem
If finding max/min: traverse the hash structure, maintain tracking variables
If order-sensitive (first non-repeating): re-traverse the original string, check hash structure
If comparing two datasets: build two Phase 1 structures, then compare element by element

Visual Explanation

Semantic Network

Key Properties

Problem-dependent — Phase 2 looks different for every problem type
May or may not be O(n) — depends on whether it traverses the structure or re-traverses the input
For array-based Phase 1: traversal is over domain size (26), input re-traversal is over n
For map-based Phase 1: traversal is over distinct elements (m ≤ n), input re-traversal is over n
Some queries can short-circuit early (first non-repeating can stop at first match)

Connections

Built from: Hashing Store Phase — Phase 2 consumes data produced by Phase 1
Built from: Two-Phase Hashing Paradigm — Phase 2 is the second half of the paradigm
Builds into: Most Frequent Character — traverses structure tracking max
Builds into: First Non-Repeating Character — re-traverses input checking structure
Builds into: Anagram Detection — compares two structures

Edge Cases & Gotchas

For first non-repeating character, the naive Phase 2 is O(n²) without the hash structure — the hash makes it O(n)
Most frequent character with ties: which character do you return? The problem usually expects any or the first; clarify with the interviewer
For maps, traversal order is non-deterministic — do not rely on order for correctness
For anagrams, comparing two maps must account for characters present in one but not the other

hashing-store-phase

2026-07-03T00:00:00.000Z

Formal Definition

The hashing store phase (Phase 1) is the process of iterating over an input sequence and populating a hash structure (array or hash map) with frequency counts or other aggregated information. It is the data-ingestion step of the two-phase hashing paradigm.

Explanation

Phase 1 is mechanical: choose your structure, loop through the input, and for each element, update its count. There is no decision-making, no comparisons, no conditional logic — just raw accumulation. This mechanical uniformity is why beginners can complete Phase 1 but then get stuck: the real thinking comes in Phase 2.

How It Works

Initialize the structure: int freq[26] = {0} or unordered_map<char,int> freq
Iterate through each character in the input string
For arrays: compute index = ch - 'a', then freq[index]++
For maps: simply freq[ch]++
After iteration, the structure contains all frequency information

Visual Explanation

Semantic Network

Key Properties

Always O(n) time — must visit each element once
O(k) space where k is the domain size (for arrays) or O(m) where m is distinct elements (for maps)
Structure choice (array vs map) is locked in during Phase 1
No conditional logic — just increment operations
Order of iteration does not matter for frequency counting

Connections

Built from: Frequency Array — one implementation choice for Phase 1
Built from: Unordered Map for Frequency — another implementation choice for Phase 1
Builds into: Two-Phase Hashing Paradigm — Phase 1 is the first half of the paradigm
Builds into: Hashing Retrieval Phase — Phase 1 feeds data into Phase 2
Related: Character-to-Index Mapping — used only in the array variant of Phase 1

Edge Cases & Gotchas

For empty strings, Phase 1 produces an empty structure — Phase 2 must handle this
For strings with a single character, the structure has one entry — still correct
For maps, repeated freq[ch]++ calls may trigger rehashing (amortized O(1), but costly)
Phase 1 cannot answer any question about the data until it completes — it is purely a gathering phase

index-to-character-conversion

2026-07-03T00:00:00.000Z

Formal Definition

Index-to-character conversion is the inverse of character-to-index mapping. Given an integer index i (0–25 for lowercase English), adding the base character’s ASCII value produces the corresponding character: ch = i + 'a'.

$\text{char}(i) = \text{ASCII}^{-1}(\text{ASCII}('a') + i)$

Explanation

After building a frequency array, the stored data is indexed numerically (0–25). To produce human-readable output (printing “a = 3” not “0 = 3”), you must convert each index back to its character. This is the reverse of the ch - 'a' mapping and uses i + 'a'.

How It Works

During traversal of the frequency array, you have an index i (0 to 25)
Compute char ch = i + 'a'
Use ch for output or further processing
For i=0 → ‘a’, i=1 → ‘b’, …, i=25 → ‘z’

Mathematical Formulation

$\text{char}(i) = i + 97 = i + \text{ASCII}('a')$

$\text{char}(0) = 'a', \quad \text{char}(1) = 'b', \quad \dots, \quad \text{char}(25) = 'z'$

Visual Explanation

Semantic Network

Key Properties

O(1) computation — simple integer addition
Must match the base used in the forward mapping ('a' for ch - 'a')
Produces only lowercase letters when used with 0–25 indices
No bounds checking — caller must ensure index is in valid range

Connections

Built from: Character-to-Index Mapping — index-to-character is the mathematical inverse of character-to-index
Builds into: Most Frequent Character — after finding the max index, convert back to character
Builds into: Frequency Array — used during the traversal phase to produce output
Contrasts with: Hash Map Traversal Method — maps store key-value pairs directly, no conversion needed

Edge Cases & Gotchas

Using 'A' as base when the mapping used 'a' produces wrong letters
Indices outside 0–25 produce non-alphabetic characters (e.g., i=26 → ’{’)
Forgetting this step and printing raw indices is a common beginner mistake
When using uppercase mapping (ch - 'A'), the reverse must use i + 'A'

two-phase-hashing

2026-07-03T00:00:00.000Z

Formal Definition

Two-phase hashing is the conceptual separation of hash-based problem solving into two distinct phases: Phase 1 (information storage) builds the frequency or mapping structure by processing the input, and Phase 2 (information retrieval) queries that structure to answer the specific problem. Both phases use the same underlying hash structure but with different access patterns.

Explanation

Beginners often stop after building the frequency structure, unsure what to do next. The key insight is that building the hash is only half the work — the real problem-solving happens in Phase 2, where you traverse or query the structure differently depending on the question. Different problems (most frequent, first non-repeating, anagram detection) all share Phase 1 but diverge in Phase 2.

How It Works

Phase 1 (Store): Choose a structure (array or hash map), iterate the input, populate frequencies
Phase 2 (Use): Query the structure — this could mean finding the max, re-traversing the input for order, or comparing two frequency maps
The distinction is mental but powerful: it separates mechanical work from analytical work

Mathematical Formulation

$\text{Phase 1: } H \leftarrow \text{build}(S) \quad \text{where } H \text{ is the hash structure}$

$\text{Phase 2: } \text{answer} \leftarrow \text{query}(H, S) \quad \text{or} \quad \text{answer} \leftarrow \text{query}(H)$

Visual Explanation

Semantic Network

Key Properties

Universal pattern across all hash-based string problems
Phase 1 is nearly identical across problems — only the structure type varies
Phase 2 varies significantly — this is where problem-specific logic lives
Understanding this separation is the threshold between beginner and intermediate problem-solving
Enables modular thinking: change Phase 2 without modifying Phase 1

Connections

Built from: Hashing Store Phase — Phase 1 is the foundation
Built from: Hashing Retrieval Phase — Phase 2 is the query layer
Builds into: Most Frequent Character — uses Phase 1 + Phase 2 (traverse struct for max)
Builds into: First Non-Repeating Character — uses Phase 1 + Phase 2 (re-traverse string)
Builds into: Anagram Detection — uses Phase 1 for two strings + Phase 2 (compare)
Related: Character Hashing Use Cases — catalog of problems following this pattern

Edge Cases & Gotchas

Some problems can be solved in one pass (Phase 1 and 2 interleaved) — the two-phase model is conceptual, not always sequential
For first non-repeating character, Phase 2 re-traverses the original string, not the hash structure — a common confusion point
For anagram detection, Phase 1 runs twice (once per string), then Phase 2 compares — the phases apply per-string
Overlapping Phase 1 and 2 can be more efficient but harder to reason about

unordered-map-frequency

2026-07-03T00:00:00.000Z

Formal Definition

An unordered map (hash map) for frequency counting uses std::unordered_map<Key, int> where each key is an element from the input and the mapped value is its occurrence count. Unlike a frequency array, the map only stores entries for elements that actually appear, and keys can be of any hashable type.

Explanation

When the character range is unknown, large, or non-contiguous (e.g., mixed case, digits, Unicode), a frequency array becomes impractical. An unordered_map<char, int> stores only the characters that actually appear, with no ASCII math needed — freq[ch] works directly. The tradeoff is hashing overhead, potential collisions, and non-deterministic iteration order.

How It Works

Declare unordered_map<char, int> freq
Iterate through the string: for(char ch : s) { freq[ch]++; }
The map automatically creates new key-value pairs for new characters
To query: iterate key-value pairs or check specific keys
No conversion needed — character is used as the key directly

Visual Explanation

Semantic Network

Key Properties

Average O(1) insertion and lookup (amortized, may degrade to O(n) with collisions)
Only stores distinct elements — memory proportional to unique characters, not domain size
Keys can be any hashable type: char, string, int, long long
No ch - 'a' conversion needed — eliminates ASCII math entirely
Iteration order is unspecified and non-deterministic

Connections

Built from: Hash Map Flexibility — unordered_map supports diverse key types
Built from: Hash Collision Overhead — the performance tradeoff of hash maps
Builds into: Two-Phase Hashing Paradigm — maps are one implementation choice for Phase 1
Builds into: Anagram Detection — maps are ideal when character set is unknown
Contrasts with: Frequency Array — array is faster for small known ranges; map is more flexible
Related: ASCII Math Elimination — maps eliminate the need for index conversion

Edge Cases & Gotchas

freq[ch]++ creates an entry with value 0 if the key does not exist, then increments — no manual insertion needed
Repeated insertions may trigger rehashing, which is O(n) amortized but can be a latency spike
unordered_map is not ordered — if you need sorted output, use map (O(log n) per operation) or sort the result
For small datasets (like lowercase-only strings), a map is slower than a frequency array despite both being O(1) — the constant factors matter
Memory per entry is higher than an array slot due to key storage, hash table overhead, and pointer chains