Exercise 3: Mapping Real Code Patterns to This Chapter's Connections — Possible Solution
====================================================================================

(A) CHECKING IF A USERNAME EXISTS BY SCANNING A LIST — DICT/SET O(1)
LOOKUPS VS. LIST O(n) SEARCH (CHAPTER 2)
------------------------------
Scanning every element of a Python list to check for a match is a
direct example of the O(n) list-search behavior this chapter's own
connections table contrasts against a dictionary or set lookup, which
would find the same answer in effectively constant time regardless of
how many usernames exist.

(B) TWO NESTED LOOPS COMPARING EVERY PAIR OF ITEMS — SPOTTING
ACCIDENTAL O(n^2) NESTED LOOPS (CHAPTER 3-4)
------------------------------
Comparing every item against every other item using two nested loops
is exactly the "innocent-looking nested loop" this chapter's own
connections table names as the single most common accidental
performance bug - each of the n outer iterations triggers n more inner
iterations, producing n^2 total comparisons.

(C) REPEATEDLY HALVING A SORTED LIST TO FIND A TARGET VALUE —
SEARCHING & SORTING (CHAPTER 7), FORESHADOWED BY THIS CHAPTER'S OWN
BINARY SEARCH EXAMPLE
------------------------------
Repeatedly halving a sorted list to home in on a target value is
precisely the binary search algorithm this chapter's own opening
comparison used - directly exemplifying the "sort first, then search
efficiently" connection named in this chapter's own five-connections
table, to be covered in full in Chapter 7.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each code pattern is matched to its connection by identifying the
specific structural feature actually present in the code - a single
linear scan, two nested loops, or a repeated halving pattern - rather
than by surface-level similarity to the chapter's own worked examples
alone.