1. Empty input
2. A single element
3. Duplicate values
4. A missing target
5. The largest allowed input

Then add cases that fit the domain: negative values, reverse-sorted data, disconnected graphs, cycles, or repeated updates.

Edge cases are not afterthoughts. They reveal whether the algorithm’s assumptions are actually true.

Use the complete checklist in the free Algorithms Made Simple Quick Reference.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post Five Edge Cases to Test Before Calling an Algorithm Finished appeared first on ChoralSoft.

Choose a stack when the newest unfinished item should be handled first. Think undo history, nested brackets, backtracking, or depth-first traversal.

Choose a queue when items should be handled in arrival order. Think task processing, customer lines, event streams, or breadth-first traversal.

The deciding question is simple: should the next item be the most recent one or the oldest waiting one?

Find more data-structure guidance in How to Choose the Right Data Structure.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post Stack or Queue? A Simple Way to Choose appeared first on ChoralSoft.

• O(1): the work stays roughly constant.
• O(log n): the problem shrinks dramatically each step.
• O(n): each item is examined once.
• O(n log n): common territory for efficient comparison sorting.
• O(n²): many pairs are compared.

The goal is not to memorize symbols in isolation. Ask what operation repeats, how often it repeats, and which term dominates for large inputs.

See the full complexity table in the free quick-reference PDF.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post Big-O in Plain Language appeared first on ChoralSoft.

Choral Software has released a free two-page Algorithms Made Simple Quick Reference. It includes:

• Big-O complexity at a glance
• Six reusable problem-solving patterns
• A data-structure chooser
• A repeatable six-step solution process
• An edge-case testing checklist

Download the free PDF

For visual explanations and worked examples, visit the Algorithms Made Simple book page.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post Free Algorithm Cheat Sheet: Complexity, Patterns, and Data Structures appeared first on ChoralSoft.

When a solution feels complicated, the problem is often not the algorithm yet. It is the way the data is represented. Start by asking what the program must do most often.

Start with the key operation

Do you need fast indexed access, membership checks, ordered processing, repeated minimum retrieval, or relationships between objects? The answer narrows the choices quickly.

Array or list: access by position

Use an array or list when order matters and you frequently access items by index. Iteration is simple and cache-friendly. Appending is often efficient, but inserting near the front may require shifting many elements.

Good for: sequences, tables, buffers, and collections processed in order.

Hash set or map: membership and lookup

Use a set when the main question is “Have I seen this value?” Use a map when a key must lead to a value, count, or record. Average lookup is constant time, but the structure uses extra memory and does not naturally express sorted order.

Good for: counting frequencies, deduplication, caching, and matching identifiers to records.

Stack: last in, first out

A stack removes the most recently added item first. This mirrors nested work: the latest unfinished task must be completed before returning to the earlier one.

Good for: parsing brackets, undo systems, depth-first traversal, and explicit recursion.

Queue: first in, first out

A queue processes items in arrival order. It is the natural model for fair scheduling and level-by-level exploration.

Good for: breadth-first search, task processing, event pipelines, and simulations.

Heap or priority queue: repeated best choice

A heap keeps the smallest or largest priority item easy to remove without fully sorting everything. It is especially useful when new candidates keep arriving.

Good for: schedulers, top-k problems, shortest-path algorithms, and merging sorted streams.

Tree: hierarchy and ordered search

Trees represent parent-child structure. Specialized balanced search trees support ordered insertion, lookup, and range queries. Tries organize strings by shared prefixes.

Good for: file systems, syntax trees, indexes, autocomplete, and hierarchical categories.

Graph: relationships and routes

Choose a graph when connections are as important as the items themselves. An adjacency list is usually compact for sparse graphs; an adjacency matrix makes direct edge checks simple but may use much more space.

Good for: roads, dependencies, social links, networks, recommendations, and state transitions.

A quick decision sequence

1. Write down the operations the program performs.
2. Identify which operation dominates runtime or complexity.
3. Choose the simplest structure that makes that operation efficient.
4. Check the memory cost and whether ordering is required.
5. Test the structure against empty, duplicate, and maximum-size inputs.

Do not optimize the wrong thing

A hash map is not automatically better than a list, and a tree is not automatically more sophisticated than an array. The best choice is contextual. If a collection has five items and is scanned once, a straightforward list may be clearer and faster in practice than a more elaborate structure.

Choose for the real workload, document the tradeoff, and measure when performance matters.

Keep the major choices nearby with the free Algorithms Made Simple Quick Reference, then continue with the full guide on the book page.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post How to Choose the Right Data Structure appeared first on ChoralSoft.

The core idea

Imagine a sorted row of 32 numbered cards. A linear search may inspect all 32. Binary search checks the middle card first. If the target is smaller, everything to the right can be ignored. If it is larger, everything to the left can be ignored.

After one comparison, 32 possibilities become 16. Then 16 become 8, 8 become 4, and 4 become 2. This repeated halving is why binary search runs in O(log n) time.

A visual walkthrough

Suppose we want to find 23 in this sorted list:

[3, 7, 11, 15, 19, 23, 27, 31, 35]

1. Check the middle: the middle value is 19.
2. Compare: 23 is greater than 19, so discard 19 and everything before it.
3. Check the new middle: in [23, 27, 31, 35], choose 27.
4. Compare again: 23 is smaller than 27, so discard 27 and everything after it.
5. Finish: the remaining candidate is 23.

The answer required only three comparisons. A linear scan would have needed six.

The condition that makes it work

Binary search needs structure. For a direct value lookup, the data must be sorted. More generally, the question being tested must be monotonic: once the answer changes from no to yes, it must not change back again.

This broader form lets binary search solve more than lookups. It can find the smallest capacity that completes a task, the earliest day a threshold is reached, or the first position where a condition becomes true.

A dependable implementation

left = 0
right = length - 1

while left <= right:
    middle = left + (right - left) // 2

    if values[middle] == target:
        return middle
    if values[middle] < target:
        left = middle + 1
    else:
        right = middle - 1

return not_found

Common mistakes

• Using binary search on unsorted data.
• Mixing inclusive and exclusive boundary rules.
• Forgetting to move past the middle element.
• Returning any match when the problem asks for the first or last match.
• Ignoring empty input or a missing target.

How to reason about correctness

At every step, maintain one promise: if the target exists, it remains inside the current search interval. Each comparison removes only the half that cannot contain the answer. When the interval becomes empty, the target is not present.

When to reach for binary search

Look for sorted collections, ordered answer spaces, and questions containing phrases such as “first valid,” “smallest possible,” “largest allowed,” or “minimum capacity.” These are strong clues that repeated halving may work.

Download the free Algorithms Made Simple Quick Reference, or explore the full visual guide on the Algorithms Made Simple book page.

Adapted from Algorithms Made Simple, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.

The post Binary Search Explained Visually appeared first on ChoralSoft.