You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<spanclass="menu-text"><spanclass="chapter-number">7</span> <spanclass="chapter-title">Linear Time Sorting</span></span></a>
193
+
<spanclass="menu-text"><spanclass="chapter-number">6</span> <spanclass="chapter-title">Linear Time Sorting</span></span></a>
194
194
</div>
195
195
</li>
196
196
<liclass="sidebar-item">
@@ -262,13 +262,10 @@
262
262
<h2id="toc-title">Table of contents</h2>
263
263
264
264
<ul>
265
-
<li><ahref="#what-is-an-algorithm" id="toc-what-is-an-algorithm" class="nav-link active" data-scroll-target="#what-is-an-algorithm"><spanclass="header-section-number">1.1</span> What is an Algorithm?</a></li>
<li><ahref="#measuring-efficiency-time-space-and-scaling" id="toc-measuring-efficiency-time-space-and-scaling" class="nav-link" data-scroll-target="#measuring-efficiency-time-space-and-scaling"><spanclass="header-section-number">1.3</span> Measuring Efficiency: Time, Space, and Scaling</a>
268
-
<ulclass="collapse">
269
-
<li><ahref="#the-unitary-cost-model" id="toc-the-unitary-cost-model" class="nav-link" data-scroll-target="#the-unitary-cost-model"><spanclass="header-section-number">1.3.1</span> The Unitary Cost Model</a></li>
270
-
</ul></li>
271
-
<li><ahref="#final-words" id="toc-final-words" class="nav-link" data-scroll-target="#final-words"><spanclass="header-section-number">1.4</span> Final Words</a></li>
265
+
<li><ahref="#what-is-an-algorithm" id="toc-what-is-an-algorithm" class="nav-link active" data-scroll-target="#what-is-an-algorithm">What is an Algorithm?</a></li>
<p>Before we begin our journey through specific algorithms, we must establish the ground on which we stand. To study algorithms is to study the limits of what can be computed and the cost of doing so.</p>
<h2data-number="1.1" class="anchored" data-anchor-id="what-is-an-algorithm"><spanclass="header-section-number">1.1</span>What is an Algorithm?</h2>
295
+
<sectionid="what-is-an-algorithm" class="level2">
296
+
<h2class="anchored" data-anchor-id="what-is-an-algorithm">What is an Algorithm?</h2>
300
297
<p>At its simplest, an algorithm is a procedure that takes an input and produces an output. However, in this Codex, we view an algorithm as a <strong>formal mathematical object</strong>—a precise strategy that exploits the structure of data to achieve an outcome efficiently.</p>
301
298
<p>To be considered a valid algorithm in our context, a procedure must satisfy several key characteristics:</p>
<p>Most academic texts rely on <strong>pseudo-code</strong>—a high-level, informal description of an algorithm. While pseudo-code is useful for broad strokes, it often hides subtle complexities and can be interpreted in multiple ways.</p>
308
305
<p>In <strong>The Algorithm Codex</strong>, we deliberately avoid pseudo-code in favor of actual, runnable <strong>Python 3.13</strong>. By using a real programming language, we ensure that every operation is precisely defined and that the implementations you see are ready to be tested, scrutinized, and executed. This approach removes the “translation layer” between theory and practice, making the logic transparent and absolute.</p>
<p>Following the definition of what an algorithm is, we must establish a framework for evaluating them. Once an implementation is complete, the work of a computer scientist is only beginning. We must subject our solution to a rigorous three-step analysis to ensure it is not just a working program, but a complete solution to a computational problem.</p>
313
310
<p>When we finish writing an algorithm, we must ask ourselves three fundamental questions. Only when all three are answered can we consider our work in computer science truly satisfied.</p>
<p>The final question is perhaps the most profound: <strong>Is this the most efficient algorithm possible, or can there be a better one?</strong> We are not just looking for a “fast” algorithm; we are looking for the theoretical limits of the problem itself. Throughout this Codex, we will try to provide intuitive proofs of <strong>optimality</strong>—explaining why a certain complexity (like O(nlogn) for comparison-based sorting) cannot be improved upon.</p>
320
317
<p>When we can prove—even intuitively—that we have reached the optimal efficiency for a correct algorithm, we have solved the problem completely. At that point, the computational task is no longer a mystery; it is a solved piece of the science of computation.</p>
<h2data-number="1.3" class="anchored" data-anchor-id="measuring-efficiency-time-space-and-scaling"><spanclass="header-section-number">1.3</span>Measuring Efficiency: Time, Space, and Scaling</h2>
<p>Once we have established that an algorithm is correct, we must ask how much it “costs” to run. In this book, we care about two primary resources: <strong>Time</strong> (the number of operations performed) and <strong>Space</strong> (the amount of memory required).</p>
<h3data-number="1.3.1" class="anchored" data-anchor-id="the-unitary-cost-model"><spanclass="header-section-number">1.3.1</span> The Unitary Cost Model</h3>
327
322
<p>Because hardware changes so rapidly, it is rarely useful to talk about runtime in terms of seconds or memory in terms of megabytes. A sorting algorithm that takes ten seconds on a vintage machine might take a fraction of a millisecond on a modern supercomputer. To remain hardware-agnostic, we fix a <strong>unitary unit of cost</strong>.</p>
328
323
<p>We assume that “atomic” operations—such as variable assignment, basic arithmetic, or printing to the console—each take exactly <strong>one unit of time</strong>. Similarly, we assume that atomic data types—like a single number or a character—occupy <strong>one unit of memory</strong>. By counting these units, we can discuss the cost of an algorithm as a mathematical function of its input.</p>
329
324
<p>However, we rarely care about the absolute number of steps. Knowing that a specific sort takes exactly 1,024 operations is less useful than knowing how that cost grows as the input size <spanclass="math inline">\(n\)</span> increases.</p>
<p>By focusing on these growth rates, we can determine the “efficiency ceiling” of our solutions and decide whether we have found the optimal approach for a given problem.</p>
<p>Now that we have settled our expectations, you are ready to start the journey. It will be fast-paced but–I hope–really exciting. We will discover many algorithms, close to a hundred of them! And in each case, we ill ask ourselves these same three questions. And, surprisingly often, we will be able to answer them pretty well!</p>
0 commit comments