Format Vol1 Python blocks; fix Fig 7.6 caption widow; tighten Listing 6.7

Bring Vol1 display code blocks into Black display-70 compliance so the CI pre-commit pass makes no modifications. Tighten Listing 6.7 by putting the attention-scores comment on its own line above the single-line computation and dropping the redundant Core computational pattern comment. Trim the Figure 7.6 caption to pull utilization onto the previous line and remove a one-word widow. Shorten the training Step 3 comment to avoid a wrapped line.

Author: profvjreddi

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

@@ -2708,13 +2708,13 @@ These metrics interact through unavoidable trade-offs. Optimizing for high throu
 
 Deployment scenario determines the priority order among those metrics. The operational constraints and success criteria vary dramatically across contexts, so metric priorities help engineers focus benchmarking effort and interpret results within the right decision framework. @Tbl-metric-priorities illustrates how performance priorities shift across five major deployment contexts, revealing the systematic relationship between operational constraints and optimization targets.
 
-| **Deployment Context**     | **Primary Priority** | **Secondary Priority** | **Tertiary Priority** | **Key Design Constraint**                         |
-|:---------------------------|:---------------------|:-----------------------|:----------------------|:--------------------------------------------------|
-| **Real-Time Applications** | Latency (p95 < 50 ms)| Reliability (99.9%)    | Memory Footprint      | User experience demands immediate response        |
-| **Cloud-Scale Services**   | Throughput (QPS)     | Cost Efficiency        | Average Latency       | Business viability requires massive scale         |
-| **Edge/Mobile Devices**    | Power Consumption    | Memory Footprint       | Latency               | Battery life and resource limits dominate         |
-| **Training Workloads**     | Training Time        | GPU Utilization        | Memory Efficiency     | Research velocity enables faster experimentation  |
-| **Scientific/Medical**     | Accuracy             | Reliability            | Explainability        | Correctness cannot be compromised for performance |
+| **Deployment Context**     | **Primary Priority**  | **Secondary Priority** | **Tertiary Priority** | **Key Design Constraint**                         |
+|:---------------------------|:----------------------|:-----------------------|:----------------------|:--------------------------------------------------|
+| **Real-Time Applications** | Latency (p95 < 50 ms) | Reliability (99.9%)    | Memory Footprint      | User experience demands immediate response        |
+| **Cloud-Scale Services**   | Throughput (QPS)      | Cost Efficiency        | Average Latency       | Business viability requires massive scale         |
+| **Edge/Mobile Devices**    | Power Consumption     | Memory Footprint       | Latency               | Battery life and resource limits dominate         |
+| **Training Workloads**     | Training Time         | GPU Utilization        | Memory Efficiency     | Research velocity enables faster experimentation  |
+| **Scientific/Medical**     | Accuracy              | Reliability            | Explainability        | Correctness cannot be compromised for performance |
 
 : **Performance Metric Priorities by Deployment Context**: Different operational environments demand distinct optimization focuses, reflecting varying constraints and success criteria. These priorities guide both benchmark selection and result interpretation. {#tbl-metric-priorities tbl-colwidths="[18,19,18,17,28]"}
 

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

@@ -1562,7 +1562,6 @@ Just as systems engineers memorize latency numbers, ML engineers should internal
 
 @Tbl-data-engineering-time-constants extends the picture with characteristic durations for labeling, training, and serving operations.
 
-
 ```{python}
 #| echo: false
 
@@ -1661,7 +1660,6 @@ class DataEngineeringTimeConstants:
 
 : **Data Engineering Time Constants**: Characteristic durations for labeling, training, and serving operations span about `{python} DataEngineeringTimeConstants.span_orders_str` orders of magnitude. Human labeling sets the wall-clock floor for new datasets, making it the dominant scheduling constraint in production ML systems. {#tbl-data-engineering-time-constants tbl-colwidths="[40,34,36]"}
 
-
 All cost figures reflect approximate 2024 cloud provider rates and are intended to convey relative magnitudes rather than exact pricing.[^fn-pricing-cost-ratios] The consistent pattern across these numbers is that human labor (labeling, annotation, expert review) dominates hardware and storage costs by one to three orders of magnitude. A team that optimizes its labeling pipeline before scaling compute or storage addresses the largest cost term first.
 
 ```{python}

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

@@ -2164,9 +2164,9 @@ An `{python} FixmatchLabelEfficiency.cost_reduction_mult_str` cost reduction for
 
 The systems trade-off in semi-supervised learning is straightforward: it typically achieves the same accuracy as fully supervised training with 5--10$\times$ fewer labels but requires more compute because training processes both labeled and unlabeled samples. Since labeling costs often dominate compute costs in production settings, this trade-off is usually favorable. A CIFAR-10 comparison makes this label efficiency concrete.
 
-| **Label Budget**                                                                                                                              | **Method**       |                                                    **Accuracy** |                                                                              **Label Efficiency** |
+| **Label Budget**                                                                                                                              | **Method**       |                           **Accuracy**                          |                                                                              **Label Efficiency** |
 |:----------------------------------------------------------------------------------------------------------------------------------------------|:-----------------|:---------------------------------------------------------------:|--------------------------------------------------------------------------------------------------:|
-| **`{python} FixmatchLabelEfficiency.cifar10_full_labels_str` (`{python} FixmatchLabelEfficiency.cifar10_full_frac_pct_str`)**                 | Fully Supervised |         `{python} FixmatchLabelEfficiency.cifar10_full_acc_str` |                                                                                          Baseline |
+| **`{python} FixmatchLabelEfficiency.cifar10_full_labels_str` (`{python} FixmatchLabelEfficiency.cifar10_full_frac_pct_str`)**                 | Fully Supervised |     `{python} FixmatchLabelEfficiency.cifar10_full_acc_str`     |                                                                                          Baseline |
 | **`{python} FixmatchLabelEfficiency.cifar10_fixmatch_4k_labels_str` (`{python} FixmatchLabelEfficiency.cifar10_fixmatch_4k_frac_pct_str`)**   | FixMatch         |  `{python} FixmatchLabelEfficiency.cifar10_fixmatch_4k_acc_str` |  `{python} FixmatchLabelEfficiency.cifar10_fixmatch_4k_efficiency_factor_mult_str` more efficient |
 | **`{python} FixmatchLabelEfficiency.cifar10_fixmatch_250_labels_str` (`{python} FixmatchLabelEfficiency.cifar10_fixmatch_250_frac_pct_str`)** | FixMatch         | `{python} FixmatchLabelEfficiency.cifar10_fixmatch_250_acc_str` | `{python} FixmatchLabelEfficiency.cifar10_fixmatch_250_efficiency_factor_mult_str` more efficient |
 | **`{python} FixmatchLabelEfficiency.cifar10_fixmatch_40_labels_str` (`{python} FixmatchLabelEfficiency.cifar10_fixmatch_40_frac_pct_str`)**   | FixMatch         |  `{python} FixmatchLabelEfficiency.cifar10_fixmatch_40_acc_str` |  `{python} FixmatchLabelEfficiency.cifar10_fixmatch_40_efficiency_factor_mult_str` more efficient |
@@ -2604,11 +2604,11 @@ Together, augmentation, generative synthesis, and distillation complete the thir
 
 When labeling budget, redundancy, rare classes, privacy, and convergence speed all matter at once, the practitioner first has to identify which constraint is binding. Each stage raises the information-compute ratio by a different mechanism: pruning removes low-value samples before training, dynamic selection focuses compute on high-value samples during training, and synthesis creates new high-value samples on demand (@tbl-data-selection).
 
-| **Stage**                | **When Applied** | **Techniques**                                        |                                    **Typical Gains** |
+| **Stage**                | **When Applied** | **Techniques**                                        | **Typical Gains**                                    |
 |:-------------------------|:-----------------|:------------------------------------------------------|:-----------------------------------------------------|
-| **Static pruning**       | Before training  | Coreset Selection, Deduplication, Quality Filtering   |                             30–50% dataset reduction |
+| **Static pruning**       | Before training  | Coreset Selection, Deduplication, Quality Filtering   | 30–50% dataset reduction                             |
 | **Dynamic selection**    | During training  | Curriculum Learning, Active Learning, Semi-Supervised | 10–30% faster curricula; 2--100$\times$ fewer labels |
-| **Synthetic generation** | On-demand        | Augmentation, Generative Models, Distillation         |               2--10$\times$ effective data expansion |
+| **Synthetic generation** | On-demand        | Augmentation, Generative Models, Distillation         | 2--10$\times$ effective data expansion               |
 
 : **Three-Stage Data Selection Pipeline**: When each stage applies, its representative techniques, and the efficiency gains typically reported for each. {#tbl-data-selection .striped .hover tbl-colwidths="[23,21,28,28]"}
 

book/quarto/contents/vol1/frameworks/frameworks.qmd

@@ -1412,7 +1412,7 @@ Fusion wins on two fronts at once. Collapsing two launches into one halves the p
 
 @Fig-python-tax makes the dispatch tax visible: eager execution creates gaps where the GPU sits idle while Python dispatches the next kernel. The blue compute regions are short; the red dispatch regions are comparatively long. Compilation fuses these operations into a single kernel launch, replacing many dispatch gaps with one dispatch block and one fused compute block.
 
-::: {#fig-python-tax fig-env="figure" fig-pos="htb" fig-cap="**The Python Tax**: Visualizing the overhead analysis from the preceding callout. In Eager Mode (top), the GPU (blue) finishes processing each op in microseconds but must sit idle while the Python interpreter (red) dispatches the next kernel launch. Compilation (bottom) fuses these operations into one kernel launch, reducing repeated dispatch gaps and improving utilization." fig-alt="Gantt chart of execution timeline. Eager mode shows alternating red Python dispatch and blue GPU kernel blocks. Compiled mode shows one red dispatch block followed by one fused blue compute block."}
+::: {#fig-python-tax fig-env="figure" fig-pos="htb" fig-cap="**The Python Tax**: Visualizing the overhead analysis from the preceding callout. In Eager Mode (top), the GPU (blue) finishes processing each op in microseconds but must sit idle while the Python interpreter (red) dispatches the next kernel launch. Compilation (bottom) fuses these operations into one kernel launch, reducing dispatch gaps and improving utilization." fig-alt="Gantt chart of execution timeline. Eager mode shows alternating red Python dispatch and blue GPU kernel blocks. Compiled mode shows one red dispatch block followed by one fused blue compute block."}
 
 ```{python}
 #| echo: false
@@ -3763,6 +3763,7 @@ Complex models compose from reusable submodules\index{nn.Module!hierarchical com
 import torch
 import torch.nn as nn
 
+
 class ResidualBlock(nn.Module):
     def __init__(self, channels):
         super().__init__()
@@ -3777,6 +3778,7 @@ class ResidualBlock(nn.Module):
         x = self.bn2(self.conv2(x))
         return torch.relu(x + residual)
 
+
 class ResNet(nn.Module):
     def __init__(self, num_blocks, channels=64):
         super().__init__()
@@ -3793,6 +3795,7 @@ class ResNet(nn.Module):
         x = x.mean(dim=[2, 3])  # Global average pooling
         return self.fc(x)
 
+
 model = ResNet(num_blocks=4)
 total = sum(p.numel() for p in model.parameters())
 print(f"Total parameters: {total}")

book/quarto/contents/vol1/hw_acceleration/hw_acceleration.qmd

@@ -5882,7 +5882,6 @@ This checklist synthesizes the principles developed throughout this chapter, tra
 
 Hardware acceleration is the force that transformed machine learning from academic curiosity to practical reality, reshaping how we design both computational systems and the algorithms that run on them. The evolution from general-purpose processors to specialized AI accelerators reflects a shift toward domain-specific computing where hardware and software are co-designed to optimize specific computational patterns. The progression from CPUs through GPUs to specialized TPUs, NPUs, and wafer-scale systems demonstrates how understanding workload characteristics drives architectural innovation, creating opportunities for orders-of-magnitude performance improvements through targeted specialization.
 
-
 ```{python}
 #| echo: false
 #| label: summary-roofline-recap
@@ -5919,7 +5918,6 @@ The technical challenges of AI acceleration span multiple layers of the computin
 
 Engineers who internalize the Roofline model and arithmetic intensity analysis gain a diagnostic framework: when inference runs slower than expected, they can immediately determine whether the bottleneck lies in compute throughput, memory bandwidth, or software overhead, and then select the appropriate optimization strategy. This systems-level understanding transforms hardware selection from vendor comparison into principled engineering.
 
-
 ::: {.callout-chapter-connection title="From optimization to validation"}
 
 We have now optimized the full D·A·M stack: data selection minimized training requirements, model compression reduced algorithmic complexity, and hardware acceleration maximized machine throughput. Optimization without measurement, however, is guesswork. In @sec-benchmarking, we move from theoretical FLOPs to measured latency, applying the roofline model and statistical methods to validate our optimization claims against reality.

book/quarto/contents/vol1/ml_systems/ml_systems.qmd

@@ -251,8 +251,6 @@ pics/mobile/.style = {
 ```
 :::
 
-
-
 ```{python}
 #| echo: false
 # ┌─────────────────────────────────────────────────────────────────────────────
@@ -644,7 +642,6 @@ Throughout this book, we use the five Lighthouse Models summarized in @tbl-ml-sy
 ```
 :::
 
-
 These archetypes map naturally to deployment paradigms. Compute beasts and sparse scatter workloads gravitate toward cloud ML where resources are abundant, bandwidth hogs span cloud and edge depending on latency requirements, and tiny constraint workloads belong to TinyML. To make these abstractions concrete, we anchor each archetype to a specific model that recurs throughout this book as one of five reference workloads.
 
 To ground the abstract interdependencies of the iron law in concrete practice, we analyze these five Lighthouse Models in turn. The following summaries recap each workload from a systems perspective, connecting them to the specific iron law bottlenecks they exemplify.
@@ -1691,7 +1688,6 @@ Cloud deployments also carry operational constraints. Unpredictable usage spikes
 
 : **Edge Inference Annual TCO**: Itemized hardware, power, cooling, network, and DevOps labor costs for the on-premise T4 implementation, exposing labor as the dominant component that determines edge break-even economics. {#tbl-ml-systems-edge-tco tbl-colwidths="[33,37,30]"}
 
-
 ::: {#nbk-ml-systems-cloud-vs-edge-tco .callout-notebook title="Cloud vs. edge TCO"}
 
 **Problem**: A vision system serves `{python} CloudEdgeTCO.requests_str` daily inferences at ResNet-50 scale (`{python} CloudEdgeTCO.inference_ms_str` latency, `{python} CloudEdgeTCO.response_kb_str` response). When all costs are included (GPU hours, network egress, power, cooling, and labor, itemized in @tbl-ml-systems-cloud-tco and @tbl-ml-systems-edge-tco), is cloud or on-premises edge deployment cheaper over `{python} CloudEdgeTCO.server_life_years_str`?
@@ -2632,7 +2628,6 @@ above=0.5of $(B2.north east)!0.5!(B3.north west)$](B0){Mobile ML};
 
 :::
 
-
 ```{python}
 #| echo: false
 #| label: battery-tax
@@ -2697,7 +2692,6 @@ class BatteryTax:
 
 :::
 
-
 ::: {.column-margin}
 ![](images/svg/vol1_ml_systems_margin_003.svg){width="100%" fig-alt="Two horizontal throughput levels: a high burst line and, well below it, a lower sustained line after thermal throttling engages."}
 

book/quarto/contents/vol1/ml_workflow/ml_workflow.qmd

@@ -116,7 +116,7 @@ Here, *lifecycle* describes the stages themselves and *workflow* describes the e
     text width=25mm,
     minimum width=25mm, minimum height=23mm
   },
-  Box1/.style={Box, node distance=3.7,text width=28mm,minimum width=28mm,fill=BlueFill,draw=BlueLine 
+  Box1/.style={Box, node distance=3.7,text width=28mm,minimum width=28mm,fill=BlueFill,draw=BlueLine
   },
  Line/.style={line width=1.30pt,black!50,text=black, -{Triangle[length=3mm, width=1.75mm]}},
  Text/.style={font=\usefont{T1}{phv}{m}{n}\footnotesize,align=center
@@ -987,7 +987,6 @@ class ConstraintPropagation:
 
 :::
 
-
 ## Problem Definition {#sec-ml-workflow-problem-definition-stage-5974}
 
 Problem definition\index{Problem Definition!ML vs. traditional} in ML begins with sentences that look deceptively simple. A product manager writes: "Build a model that detects diabetic retinopathy." That single sentence conceals a dozen engineering decisions: sensitivity thresholds for patient safety, hardware capabilities in rural clinics, latency budgets that keep clinicians engaged, and regulatory frameworks governing approval. In traditional software, requirements translate directly into implementation rules. In ML systems, defining *what* the system should do is inseparable from defining *how* it will learn to do it—and the physical constraints under which it must operate. This first stage, the leftmost box in @fig-lifecycle-overview, lays the foundation for all subsequent phases in the ML lifecycle.

book/quarto/contents/vol1/model_compression/model_compression.qmd

@@ -3661,7 +3661,6 @@ FP16\index{FP16!training}\index{FP16!reduced dynamic range}\index{Quantization!F
 
 : **Numerical Precision Formats**: Comparison of precision formats by bit width, memory reduction, computational efficiency, accuracy retention, and typical use cases across deployment contexts. {#tbl-numerics tbl-colwidths="[21,10,13,18,12,26]"}
 
-
 Compare the three bit layouts in @fig-3float to see exactly where the bits go—and why the trade-off between precision and numerical range differs so sharply across formats.
 
 ::: {#fig-3float fig-env="figure" fig-pos="htb" fig-cap="**Floating-Point Precision**: Reduced-precision formats like FP16 and BF16 trade off numerical range for computational efficiency and memory savings. BF16 maintains the exponent size of FP32, preserving its dynamic range and suitability for training, while FP16's smaller exponent limits its use to inference or carefully scaled training scenarios." fig-alt="Three horizontal bit-layout diagrams. FP32 shows 1-bit sign, 8-bit exponent, 23-bit mantissa. FP16 shows 1-bit sign, 5-bit exponent, 10-bit mantissa. BF16 shows 1-bit sign, 8-bit exponent, 7-bit mantissa."}