Apply pre-commit auto-fixes (Black + blank/whitespace normalization) after merging origin/dev ch11/ch12 layout

Author: profvjreddi

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

@@ -1171,7 +1171,6 @@ Given the inherent specificity of end-to-end benchmarking, organizations typical
 
 : **Benchmarking Granularity Levels**: Different benchmark scopes target distinct stages of ML system development. Micro-benchmarks isolate individual operations for low-level optimization, macro-benchmarks evaluate complete models to guide architectural choices, and end-to-end benchmarks assess full system performance in production environments. {#tbl-benchmark-comparison tbl-colwidths="[11,30,30,29]"}
 
-
 Picking a single granularity level is rarely sufficient because a core tension exists between diagnostic precision and real-world fidelity. @Fig-benchmark-tradeoffs maps this trade-off, placing micro-benchmarks at the high-isolation end (precise but narrow) and end-to-end benchmarks at the high-representativeness end (realistic but harder to diagnose). No single point on this spectrum provides both: micro-benchmarks pinpoint exactly which kernel is slow but miss system-level bottlenecks, while end-to-end benchmarks capture production behavior but obscure root causes. The practical takeaway is that effective ML system evaluation requires combining insights from all three levels.
 
 ::: {#fig-benchmark-tradeoffs fig-env="figure" fig-pos="htb" fig-cap="**Isolation vs. Representativeness**: The core trade-off in benchmarking granularity. Micro-benchmarks provide high diagnostic precision but limited real-world relevance, while end-to-end benchmarks capture realistic system behavior but offer less precise component-level insights. Effective ML system evaluation requires strategic combination of all three levels." fig-alt="Scatter plot with three labeled points along a diagonal: micro-benchmarks at high isolation, macro-benchmarks, and end-to-end benchmarks at high representativeness."}
@@ -4006,7 +4005,7 @@ Notice in @tbl-benchmarking-mobilenet-int8-validation that aggregate accuracy ba
 **Edge-case definition**: Images with >`{python} MobileNetINT8Calc.edge_occlusion_pct_str` occlusion, <`{python} MobileNetINT8Calc.edge_lux_str` lighting, or >`{python} MobileNetINT8Calc.edge_rotation_deg_str`° rotation from training distribution (approximately `{python} MobileNetINT8Calc.real_world_edge_pct_str` of real-world inputs).
 
 ```{=latex}
-\end{minipage} 
+\end{minipage}
 ```
 
 **What this reveals**: Average-case accuracy looks acceptable (`{python} MobileNetINT8Calc.mv2_acc_drop_str` drop), but calibration degraded significantly and edge-case accuracy dropped `{python} MobileNetINT8Calc.mv2_edge_drop_str`. If the deployment context uses confidence thresholds (for example, "only act if confidence > `{python} MobileNetINT8Calc.confidence_threshold_pct_str`") or encounters many edge cases (unusual lighting, partial occlusions), INT8 MobileNetV2 may fail despite passing aggregate benchmarks.

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

@@ -612,7 +612,6 @@ The scale of this challenge becomes stark in @fig-systems-gap, which plots the s
 
 The plot is normalized to a 2012 baseline to emphasize relative growth. Notice how the purple-shaded region between the curves keeps widening—this gap cannot be closed by waiting for faster chips; it requires architectural innovation.
 
-
 ```{python}
 #| echo: false
 #| label: systems-gap-rates-calc
@@ -1178,7 +1177,8 @@ This single line of code conceals the computational complexity that accelerators
 ::: {#lst-dense_expansion lst-cap="**Matrix Operation Expansion**: Each dense layer decomposes into matrix multiplication and element-wise operations, exposing the dominant compute pattern that many neural-network kernels are built around."}
 
 ```{.python}
-# Linear transformation work scales with input_dim x output_dim x batch.
+# Linear transformation work scales with input_dim x output_dim x
+# batch.
 output = (
     matmul(input, weights) + bias
 )  # Matrix multiply dominates cost
@@ -2279,7 +2279,6 @@ The systolic array architecture achieves computational efficiency through synchr
 
 **The architects' dilemma**: Systolic arrays must choose which data to keep stationary (in registers) to minimize movement. This choice hard-codes the hardware's preference for certain model types. @Tbl-hw-acceleration-systolic-dataflow previews the three stationary-operand strategies and the workloads each favors; @sec-hardware-acceleration-dataflow-optimization-strategies-ce52 develops each one in full as a general mapping decision.
 
-
 | **Strategy**                                                     | **Stationary Item** | **Optimized For**          | **Example Workload**                                                                        |
 |:-----------------------------------------------------------------|:--------------------|:---------------------------|:--------------------------------------------------------------------------------------------|
 | **Weight-Stationary**\index{Weight-Stationary!dataflow strategy} | Weights ($W$)       | High Reuse of Weights      | **CNNs (Conv2D)**: Filters are small and reused across the entire image.                    |