Audit post-merge prose style consistency

Author: profvjreddi

book/quarto/contents/vol1/backmatter/appendix_dam.qmd

@@ -205,35 +205,35 @@ The iron law tells you *how much* time each axis consumes. But it leaves one cri
 
 ## Arithmetic Intensity Boundary {#sec-dam-taxonomy-arithmetic-intensity-boundary-7f5e}
 
-The boundary between **Data** (Memory Bound) and **Machine** (Compute Bound) is not arbitrary; it is defined mathematically by the **Arithmetic Intensity**[^fn-arith-intensity] ($I$) of the workload.
+The boundary between **Data** (memory bound) and **Machine** (compute bound) is not arbitrary; it is defined mathematically by **arithmetic intensity**[^fn-arith-intensity] ($I$) of the workload.
 
 [^fn-arith-intensity]: **Arithmetic Intensity**: The ratio of floating-point operations to bytes transferred (FLOPs/byte), introduced by @williams2009 as the key parameter in the Roofline Model. It determines whether a workload is memory bound or compute bound by comparison against the hardware's *ridge point* ($R_{\text{peak}}/\text{BW}$). @sec-machine-foundations-roofline-model-2529 provides a complete derivation.
 
-@sec-machine-foundations-roofline-model-2529 provides rigorous definitions of Arithmetic Intensity and the Roofline Model. Use that model to quantitatively distinguish between Data and Machine bottlenecks before applying the optimizations below.
+@sec-machine-foundations-roofline-model-2529 provides rigorous definitions of arithmetic intensity and the roofline model. Use that model to quantitatively distinguish between Data and Machine bottlenecks before applying the optimizations below.
 
 The Roofline Model provides exact answers when you have time to profile. But in the middle of a production incident, you often need a faster heuristic—a set of quick thresholds that point you toward the right axis within seconds.
 
 ## Rules of Thumb {#sec-dam-taxonomy-rules-thumb-f94f}
 
 In the heat of a production outage, you rarely have time to solve the full iron law equation. Instead, veteran systems engineers rely on these quantitative heuristics to quickly narrow down the search space. Use these thresholds as your first line of defense.
 
-*   **If Accelerator Utilization $<$ 80 percent**: You are likely **Data Bound** (or CPU bound). The accelerator is starving.
-*   **If Accelerator Utilization $>$ 95 percent**: You are likely **Machine Bound**. The accelerator is fully saturated.
-*   **If Batch Size is one**: You are likely **Latency Bound** (Algorithm overhead dominates).
-*   **If Arithmetic Intensity $<$ 100 FLOPs/byte**: You are likely **Memory Bound** (Data/Machine boundary). This threshold is approximate for current-generation accelerators; compute your hardware's specific ridge point ($R_{\text{peak}}/\text{BW}$) for a precise boundary.
-*   **If System works in Dev but fails in Prod**: Suspect **Data Drift** (Data component).
+*   **If accelerator utilization $<$ 80 percent**: The workload is likely data bound (or CPU bound). The accelerator is starving.
+*   **If accelerator utilization $>$ 95 percent**: The workload is likely machine bound. The accelerator is fully saturated.
+*   **If batch size is one**: The workload is likely latency bound (algorithm overhead dominates).
+*   **If arithmetic intensity $<$ 100 FLOPs/byte**: The workload is likely memory bound (Data/Machine boundary). This threshold is approximate for current-generation accelerators; compute the hardware's specific ridge point ($R_{\text{peak}}/\text{BW}$) for a precise boundary.
+*   **If the system works in dev but fails in prod**: Suspect data drift (Data component).
 
-Note that common industry labels map to DAM components as follows: **Memory Bound** typically indicates a **Data** bottleneck (information cannot reach the accelerator fast enough), **Compute Bound** indicates a **Machine** bottleneck (the accelerator is fully saturated), and **Latency Bound** indicates an **Algorithm** bottleneck (serial operation depth or overhead dominates).
+Common industry labels map to DAM components as follows: memory bound typically indicates a **Data** bottleneck (information cannot reach the accelerator fast enough), compute bound indicates a **Machine** bottleneck (the accelerator is fully saturated), and latency bound indicates an **Algorithm** bottleneck (serial operation depth or overhead dominates).
 
 ### Bottleneck diagnostic {#sec-dam-taxonomy-bottleneck-diagnostic-3fc9}
 
-Once you identify the bottleneck, @tbl-bottleneck-actions tells you what to do—and what NOT to do:
+Once the bottleneck is identified, @tbl-bottleneck-actions shows which optimizations help and which ones are wasted:
 
-| **If You are...** | **Dominant Term**                            | **Optimization That Works**                                       | **Optimization That is Wasted**                    |
-|:------------------|:---------------------------------------------|:------------------------------------------------------------------|:---------------------------------------------------|
-| **Memory-Bound**  | $D_{\text{vol}}/\text{BW}$                   | Quantization, pruning, batching, kernel fusion                    | Faster accelerator (more FLOP/s will not help)     |
-| **Compute-Bound** | $O/(R_{\text{peak}} \cdot \eta_{\text{hw}})$ | Better kernels, Tensor Cores, faster accelerator, lower precision | More memory bandwidth (already saturated)          |
-| **Latency-Bound** | $L_{\text{lat}}$                             | Batching requests, kernel fusion, async dispatch                  | Neither compute nor bandwidth (overhead dominates) |
+| **If the workload is...** | **Dominant Term**                            | **Optimization That Works**                                       | **Optimization That is Wasted**                    |
+|:--------------------------|:---------------------------------------------|:------------------------------------------------------------------|:---------------------------------------------------|
+| **Memory-Bound**          | $D_{\text{vol}}/\text{BW}$                   | Quantization, pruning, batching, kernel fusion                    | Faster accelerator (more FLOP/s will not help)     |
+| **Compute-Bound**         | $O/(R_{\text{peak}} \cdot \eta_{\text{hw}})$ | Better kernels, Tensor Cores, faster accelerator, lower precision | More memory bandwidth (already saturated)          |
+| **Latency-Bound**         | $L_{\text{lat}}$                             | Batching requests, kernel fusion, async dispatch                  | Neither compute nor bandwidth (overhead dominates) |
 
 : **What Works vs. What Is Wasted**: Optimizing the wrong term yields exactly zero improvement. A memory-bound large language model (LLM) will not speed up from a faster accelerator; the accelerator will simply idle faster while waiting for memory. {#tbl-bottleneck-actions}
 
@@ -293,7 +293,7 @@ Accelerator utilization is pinned at 99 percent. Memory bandwidth is unsaturated
 
 #### Diagnosis {.unnumbered}
 
-You have successfully fed the beast. The system is **Compute Bound**.
+The system has successfully fed the beast. It is compute bound.
 
 #### The fix {.unnumbered}
 

book/quarto/contents/vol1/benchmarking/benchmarking.qmd

@@ -989,7 +989,7 @@ With these measurement principles established, we can now examine how to diagnos
 
 *   **Signal**: Look for the **"Memory Throughput"** or **"DRAM Bandwidth"** line.
 *   **Calculation**: $\text{Effective BW} = \frac{\text{Total Bytes Transferred}}{\text{Kernel Duration}}$.
-*   **Diagnosis**: If $\text{Effective BW} \approx \text{Peak BW}$ (for example, >1.6 TB/s on A100), the kernel is **Memory Bound**. Optimizing compute (Ops) will do nothing.
+*   **Diagnosis**: If $\text{Effective BW} \approx \text{Peak BW}$ (for example, >1.6 TB/s on A100), the kernel is memory bound. Optimizing compute (Ops) will do nothing.
 
 **Measuring the throughput term $(\eta_{\text{hw}})$**
 

book/quarto/contents/vol1/data_engineering/data_engineering.qmd

@@ -2161,7 +2161,7 @@ If the data pipeline cannot decode images fast enough to keep the GPU busy, the
 
 Examine @fig-dataloader-choke-point to see this **Dataloader Choke Point**\index{Dataloader!dataloader choke point} in action. Notice the "Starvation Region" on the left where the CPU limits performance: no matter how powerful the GPU, training throughput is capped by data loading speed until enough workers are allocated to saturate the accelerator. Throughput levels are representative and vary by model and hardware.
 
-::: {#fig-dataloader-choke-point fig-env="figure" fig-pos="htb" fig-cap="**The Dataloader Choke Point**: Training Throughput (img/s) vs. Number of DataLoader Workers. The blue curve shows CPU throughput scaling linearly with workers until hitting disk limits. The red dashed line is the GPU's consumption capacity (for example, ResNet-50 at ~3,000 img/s; illustrative). The system is bottlenecked by whichever is lower. In the 'Starvation Region' (left), the GPU is idle waiting for data. In the 'Saturated Region' (right), the GPU is fully utilized, and adding more workers wastes CPU memory." fig-alt="Line chart of throughput vs. workers. Blue line (CPU) rises linearly. Red line (GPU) is flat. Where CPU < GPU, system is starved. Where CPU > GPU, system is saturated."}
+::: {#fig-dataloader-choke-point fig-env="figure" fig-pos="htb" fig-cap="**The Dataloader Choke Point**: Training throughput (img/s) vs. number of DataLoader workers. The blue curve shows CPU throughput scaling linearly with workers until hitting disk limits. The red dashed line is the GPU's consumption capacity (for example, ResNet-50 at ~3,000 img/s; illustrative). The system is bottlenecked by whichever is lower. In the starvation region (left), the GPU is idle waiting for data. In the saturated region (right), the GPU is fully utilized, and adding more workers wastes CPU memory." fig-alt="Line chart of throughput vs. workers. Blue line (CPU) rises linearly. Red line (GPU) is flat. Where CPU < GPU, system is starved. Where CPU > GPU, system is saturated."}
 
 ```{python}
 #| echo: false
@@ -3454,11 +3454,11 @@ The storage architectures we have examined address where data resides and how it
 
 ::: {.callout-definition title="Feature store"}
 
-***Feature Store***\index{Feature Store!definition} is the architectural layer that centralizes the management of **Machine Learning Features**, decoupling feature computation from consumption.
+***Feature Store***\index{Feature Store!definition} is the architectural layer that centralizes the management of machine learning features, decoupling feature computation from consumption.
 
-1.  **Significance (quantitative)**: It enforces **Point-in-Time Correctness**, ensuring that historical data used for training $(x_{t-\Delta})$ is computed with identical logic to the real-time data served at inference $(x_t)$, eliminating **Training-Serving Skew** by design.
-2.  **Distinction (durable)**: Unlike a **General-Purpose Database**, a Feature Store is designed for **Dual Storage Modes**: an *Offline Store* (columnar/batch) for training and an *Online Store* (key-value/low-latency) for serving.
-3.  **Common pitfall**: A frequent misconception is that a Feature Store is just "a place to store data." In reality, it is a **Transformation Engine**: it stores the *logic* to compute features consistently across the entire ML lifecycle.
+1.  **Significance (quantitative)**: It enforces point-in-time correctness, ensuring that historical data used for training $(x_{t-\Delta})$ is computed with identical logic to the real-time data served at inference $(x_t)$, eliminating training-serving skew by design.
+2.  **Distinction (durable)**: Unlike a general-purpose database, a feature store is designed for dual storage modes: an *offline store* (columnar/batch) for training and an *online store* (key-value/low-latency) for serving.
+3.  **Common pitfall**: A frequent misconception is that a feature store is just "a place to store data." In reality, it is a transformation engine: it stores the *logic* to compute features consistently across the entire ML lifecycle.
 
 :::
 
@@ -3559,7 +3559,7 @@ The key insight is that data debt,\index{Data Debt!strategic vs. unconscious} li
 
 \index{Debugging!data pipelines}\index{Pipeline!failure diagnosis}When data debt comes due, it surfaces as model accuracy degradation, pipeline failures, or subgroup performance disparities. Effective debugging applies the diagnostic principles established throughout this chapter: data cascades (@sec-data-engineering-data-cascades-systematic-foundations-matter-2efe) remind us that root causes lie upstream of symptoms, training-serving skew (@sec-data-engineering-ensuring-trainingserving-consistency-c683) explains many deployment failures, and drift detection (@sec-data-engineering-detecting-responding-data-drift-509a) surfaces gradual degradation. @fig-debug-flowchart synthesizes these concepts into an actionable diagnostic sequence:
 
-::: {#fig-debug-flowchart fig-env="figure" fig-pos="htb" fig-cap="**Data Pipeline Debugging Flowchart**: Four sequential decision nodes guide root cause diagnosis: (1) accuracy degrades over time leads to Data Drift, (2) training accuracy exceeds validation leads to Overfitting, (3) validation exceeds production accuracy leads to Training-Serving Skew, and (4) subgroup inconsistency leads to Bias. If all answers are no, the issue points to Model Architecture." fig-alt="Vertical flowchart with four blue diamond decision nodes and red result boxes. Top diamond asks if accuracy degrades over time, leading to data drift result. Second asks if training accuracy exceeds validation, leading to overfitting. Third asks if validation exceeds production accuracy, leading to training-serving skew. Fourth asks about subgroup inconsistency, leading to bias. Gray box at bottom shows model architecture issue if all answers are no."}
+::: {#fig-debug-flowchart fig-env="figure" fig-pos="htb" fig-cap="**Data Pipeline Debugging Flowchart**: Four sequential decision nodes guide root cause diagnosis: (1) accuracy degrades over time leads to data drift, (2) training accuracy exceeds validation leads to overfitting, (3) validation exceeds production accuracy leads to training-serving skew, and (4) subgroup inconsistency leads to bias. If all answers are no, the issue points to model architecture." fig-alt="Vertical flowchart with four blue diamond decision nodes and red result boxes. Top diamond asks if accuracy degrades over time, leading to data drift result. Second asks if training accuracy exceeds validation, leading to overfitting. Third asks if validation exceeds production accuracy, leading to training-serving skew. Fourth asks about subgroup inconsistency, leading to bias. Gray box at bottom shows model architecture issue if all answers are no."}
 
 ```{.tikz}
 \begin{tikzpicture}[font=\small\usefont{T1}{phv}{m}{n},line width=0.75pt]

book/quarto/contents/vol1/data_selection/data_selection.qmd

@@ -1897,9 +1897,9 @@ class ActiveLearningRoi:
 
 :::
 
-Compare the two curves in @fig-active-learning-multiplier: Active Learning shifts the learning curve to the left, achieving target accuracy with far fewer samples than random selection. The curves are illustrative to highlight the qualitative gap.
+Compare the two curves in @fig-active-learning-multiplier: active learning shifts the learning curve to the left, achieving target accuracy with far fewer samples than random selection. The curves are illustrative to highlight the qualitative gap.
 
-::: {#fig-active-learning-multiplier fig-env="figure" fig-pos="htb" fig-cap="**The Active Learning Multiplier**: Model Accuracy vs. Number of Labeled Samples (Log Scale). Random sampling (gray dashed) yields linear improvements, often requiring massive datasets to capture rare edge cases. Active Learning (green solid) targets informative samples, reaching the same accuracy with fewer labels. Curves are illustrative to show the qualitative advantage." fig-alt="Line chart of accuracy vs. labeled samples (log scale). Green line (active learning) rises much faster than gray line (random sampling). Shaded area between them shows cost savings."}
+::: {#fig-active-learning-multiplier fig-env="figure" fig-pos="htb" fig-cap="**The Active Learning Multiplier**: Model accuracy vs. number of labeled samples (log scale). Random sampling (gray dashed) yields linear improvements, often requiring massive datasets to capture rare edge cases. Active learning (green solid) targets informative samples, reaching the same accuracy with fewer labels. Curves are illustrative to show the qualitative advantage." fig-alt="Line chart of accuracy vs. labeled samples (log scale). Green line (active learning) rises much faster than gray line (random sampling). Shaded area between them shows cost savings."}
 
 ```{python}
 #| echo: false

book/quarto/contents/vol1/introduction/introduction.qmd

@@ -2055,7 +2055,7 @@ plt.close()
 
 Efficiency gains tell only half the story. @fig-ai-training-compute-growth reveals the countervailing trend: even as individual architectures become more efficient, the field's total appetite for compute has grown exponentially, making efficiency optimization not a luxury but a necessity for continued progress.
 
-::: {#fig-ai-training-compute-growth fig-env="figure" fig-pos="htb" fig-cap="**The Era of Scale**: Training Compute (FLOPs) vs. Year (Log Scale). While early Deep Learning (blue) showed rapid growth, the Transformer Era (red) accelerated this trend significantly. From AlexNet (2012) to GPT-4 (2023), compute requirements increased by $10^7$ (10 million times), far outpacing Moore's Law. This exponential demand drives the specialized infrastructure described in this book." fig-alt="Scatter plot of Training Compute FLOPs vs. Year. Blue dots (2012 – 2018) show deep learning models like ResNet. Red dots (2018 – 2024) show large - scale models like GPT-4, rising much faster on the log scale."}
+::: {#fig-ai-training-compute-growth fig-env="figure" fig-pos="htb" fig-cap="**The Era of Scale**: Training compute (FLOPs) vs. year (log scale). While early deep learning (blue) showed rapid growth, the transformer era (red) accelerated this trend significantly. From AlexNet (2012) to GPT-4 (2023), compute requirements increased by $10^7$ (10 million times), far outpacing Moore's Law. This exponential demand drives the specialized infrastructure described in this book." fig-alt="Scatter plot of Training Compute FLOPs vs. Year. Blue dots (2012 – 2018) show deep learning models like ResNet. Red dots (2018 – 2024) show large - scale models like GPT-4, rising much faster on the log scale."}
 
 ```{python}
 #| echo: false