|
| 1 | +# Changes Made: Optimization via Pre-computing |
| 2 | + |
| 3 | +## Overview |
| 4 | +These changes apply the strategy of **Pre-computing**: doing work upfront (like sorting or indexing) to make the primary search or calculation significantly faster. This allowed both algorithms to scale from small examples to datasets containing millions of items. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## 1. Longest Common Prefix Optimization (`common_prefix.py`) |
| 9 | + |
| 10 | +### The Problem |
| 11 | +The original implementation used a nested loop to compare every string in a list against every other string. |
| 12 | +- **Original Complexity**: $O(N^2)$. |
| 13 | +- **The Bottleneck**: With 1,000,000 strings, the code would perform roughly 1 trillion comparisons, causing it to hang indefinitely. |
| 14 | + |
| 15 | +### The Solution: "Sort Before Search" |
| 16 | +I implemented alphabetical sorting as a pre-computation step. |
| 17 | +- **Why it works**: In a sorted list, the strings that share the longest common prefixes are mathematically guaranteed to be **neighbors**. |
| 18 | +- **The Change**: By sorting the list first, I replaced the nested loop with a single pass that only compares each string to the one immediately following it. |
| 19 | +- **Improved Complexity**: $O(N \log N)$ for the sort + $O(N)$ for the single-pass search. |
| 20 | +- **Legacy Retention**: Kept the original `find_common_prefix` helper function and variable names (`longest`, `string`, `other_string`) to maintain code continuity. |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## 2. Count Letters Optimization (`count_letters.py`) |
| 25 | + |
| 26 | +### The Problem |
| 27 | +The original code contained a "hidden loop" inside a string iteration. |
| 28 | +- **Original Complexity**: $O(N^2)$. |
| 29 | +- **The Bottleneck**: The check `if letter.lower() not in s` required the computer to scan the entire string `s` for every character. On a 10-million-character string, this resulted in an impossible amount of work. |
| 30 | + |
| 31 | +### The Solution: "Sets for Instant Lookups" |
| 32 | +I introduced a pre-computed **Set** to handle character lookups. |
| 33 | +- **Why it works**: Searching for an item in a Python `set` (a hash table) takes **O(1) constant time**, whereas searching a `string` takes **O(N) linear time**. |
| 34 | +- **The Change**: I converted the string `s` into a set (`chars_in_string`) at the start of the function. This one-time $O(N)$ operation transformed the inner search from a slow scan into an instant lookup. |
| 35 | +- **Improved Complexity**: $O(N)$ — one pass to build the set, and one pass to loop through the string. |
| 36 | +- **Legacy Retention**: Preserved the original loop structure (`for letter in s`), the `is_upper_case` helper, and the `only_upper` variable name. |
| 37 | + |
| 38 | +--- |
| 39 | + |
| 40 | +## 3. Technical Trade-offs: Space vs. Time |
| 41 | +Both tasks are classic examples of the **Space-vs-Time trade-off**: |
| 42 | + |
| 43 | +1. **Memory (Space)**: We used extra memory to store a sorted version of the list (Task 5) and a set of unique characters (Task 6). |
| 44 | +2. **Speed (Time)**: By "spending" this memory, we drastically reduced the number of CPU operations required. |
| 45 | + |
| 46 | +**Result**: Operations that previously would have taken hours now complete in milliseconds, representing a massive gain in software scalability and performance. |
0 commit comments