mirror of
https://github.com/harvard-edge/cs249r_book.git
synced 2026-03-11 17:49:25 -05:00
feat(ui): enhance table styling and add H3 header accents
- Add enhanced table styling with lighter cell text and improved readability - Add H3 headers with thinner crimson accent bars for better hierarchy - Improve table captions with left-alignment and better typography - Add special styling for comparison table headers with subtle crimson background - Refine hover effects for better user interaction - Update HTML configuration to include additional frontmatter pages
This commit is contained in:
Vijay Janapa Reddi
@@ -88,6 +88,15 @@ h2 {
|
||||
margin-bottom: 1rem;
|
||||
}
|
||||
|
||||
// H3 headers with thinner crimson accent for hierarchy
|
||||
h3 {
|
||||
border-left: 2px solid $crimson;
|
||||
padding-left: 12px;
|
||||
margin-top: 1.5rem;
|
||||
margin-bottom: 0.75rem;
|
||||
color: #2c3e50;
|
||||
}
|
||||
|
||||
// Table styling - clean and readable
|
||||
table {
|
||||
border-collapse: collapse;
|
||||
@@ -121,14 +130,137 @@ table {
|
||||
}
|
||||
}
|
||||
|
||||
// Table captions - left aligned and properly styled
|
||||
// Table captions - left aligned with Bootstrap override
|
||||
.table-caption,
|
||||
table caption,
|
||||
div.caption {
|
||||
text-align: left;
|
||||
font-weight: 600;
|
||||
margin-bottom: 0.5rem;
|
||||
color: #495057;
|
||||
div.caption,
|
||||
.caption-text,
|
||||
.table > caption,
|
||||
.table-responsive > .table > caption,
|
||||
div[id^="tbl-"] .caption,
|
||||
div[id^="tbl-"] p,
|
||||
.cell-output-display .caption,
|
||||
.cell-output-display > p:first-child,
|
||||
.quarto-float-caption-top,
|
||||
.quarto-float-caption,
|
||||
.quarto-float-tbl,
|
||||
figcaption.quarto-float-caption-top,
|
||||
figcaption[id*="caption"] {
|
||||
text-align: left !important;
|
||||
caption-side: top !important;
|
||||
font-weight: 500 !important;
|
||||
margin-bottom: 0.75rem !important;
|
||||
margin-top: 1.5rem !important;
|
||||
color: #495057 !important;
|
||||
font-size: 0.9rem !important;
|
||||
line-height: 1.4 !important;
|
||||
padding-left: 0 !important;
|
||||
margin-left: 0 !important;
|
||||
display: block !important;
|
||||
}
|
||||
|
||||
// Target Quarto-specific table caption structure
|
||||
.quarto-figure .figure-caption,
|
||||
.panel-caption,
|
||||
.tbl-cap,
|
||||
.quarto-float-caption-top,
|
||||
.quarto-float-caption,
|
||||
.quarto-float-tbl,
|
||||
figcaption.quarto-float-caption-top {
|
||||
text-align: left !important;
|
||||
text-align-last: left !important;
|
||||
display: block !important;
|
||||
}
|
||||
|
||||
// Better table styling for academic content
|
||||
.table-container,
|
||||
.cell-output-display,
|
||||
#tbl-paradigm-evolution {
|
||||
margin: 2rem 0;
|
||||
overflow-x: auto; // Handle mobile responsiveness
|
||||
|
||||
table {
|
||||
font-size: 0.85rem;
|
||||
line-height: 1.4;
|
||||
min-width: 100%;
|
||||
|
||||
th {
|
||||
background-color: #f8f9fa;
|
||||
font-weight: 500;
|
||||
text-align: left;
|
||||
padding: 14px 12px;
|
||||
border-bottom: 2px solid $crimson;
|
||||
font-size: 0.85rem;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.3px;
|
||||
color: #2c3e50;
|
||||
white-space: nowrap; // Prevent header wrapping
|
||||
}
|
||||
|
||||
// Special treatment for technology comparison headers (not row labels)
|
||||
th:not(:first-child) {
|
||||
background-color: rgba($crimson, 0.04);
|
||||
border-bottom: 3px solid $crimson;
|
||||
font-weight: 600;
|
||||
color: darken(#2c3e50, 10%);
|
||||
}
|
||||
|
||||
td {
|
||||
text-align: left;
|
||||
padding: 12px 12px;
|
||||
border-bottom: 1px solid #e9ecef;
|
||||
vertical-align: top;
|
||||
font-weight: 300; // Lighter text for better readability
|
||||
color: #5a6369; // Slightly lighter than default
|
||||
|
||||
// Better text wrapping and readability
|
||||
word-wrap: break-word;
|
||||
hyphens: auto;
|
||||
max-width: 200px; // Prevent overly wide cells
|
||||
}
|
||||
|
||||
// First column (Aspect) - make it stand out as row headers
|
||||
td:first-child,
|
||||
th:first-child {
|
||||
font-weight: 500;
|
||||
color: #2c3e50;
|
||||
background-color: #f8f9fa;
|
||||
border-right: 1px solid #e9ecef;
|
||||
min-width: 120px;
|
||||
}
|
||||
|
||||
// Improve zebra striping contrast
|
||||
tbody tr:nth-child(even) {
|
||||
background-color: #fafbfc;
|
||||
|
||||
td:first-child {
|
||||
background-color: #f1f3f4; // Keep first column slightly different
|
||||
}
|
||||
}
|
||||
|
||||
tbody tr:hover {
|
||||
background-color: #f1f3f4;
|
||||
transition: background-color 0.2s ease;
|
||||
|
||||
td:first-child {
|
||||
background-color: #e9ecef;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Responsive table behavior
|
||||
@media (max-width: 768px) {
|
||||
.table-container,
|
||||
.cell-output-display {
|
||||
table {
|
||||
font-size: 0.75rem;
|
||||
|
||||
th, td {
|
||||
padding: 8px 6px;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@@ -26,15 +26,6 @@ project:
|
||||
preview:
|
||||
browser: true
|
||||
navigate: true
|
||||
render:
|
||||
- index.qmd
|
||||
- 404.qmd
|
||||
- contents/frontmatter/
|
||||
- contents/core/introduction/introduction.qmd
|
||||
- contents/labs/arduino/nicla_vision/nicla_vision.qmd
|
||||
# Fast build: only render essential files and target chapter
|
||||
|
||||
# No site-wide title - each page defines its own
|
||||
|
||||
website:
|
||||
# High-level navigation enhancements
|
||||
@@ -469,9 +460,6 @@ format:
|
||||
|
||||
code-block-bg: true
|
||||
|
||||
table:
|
||||
classes: [table-striped, table-hover]
|
||||
|
||||
language:
|
||||
title-block-author-single: "Author, Editor & Curator"
|
||||
title-block-published: "Last Updated"
|
||||
|
||||
@@ -1734,7 +1734,7 @@ This progression reveals not just the evolution of neural networks, but also the
|
||||
| Attention Era | Transformer | Attention, Dynamic Compute | Flexible accelerators, High-bandwidth memory |
|
||||
+-------------------+-----------------------+----------------------------+----------------------------------------------+
|
||||
|
||||
: **Deep Learning Evolution**: Neural network architectures have progressed from simple, fully connected layers to complex models leveraging specialized hardware and addressing sequential data dependencies. This table maps architectural eras to key computational primitives and corresponding system-level optimizations, revealing a historical trend toward increased parallelism and memory bandwidth requirements. {#tbl-dl-evolution .hover .striped}
|
||||
: **Deep Learning Evolution**: Neural network architectures have progressed from simple, fully connected layers to complex models leveraging specialized hardware and addressing sequential data dependencies. This table maps architectural eras to key computational primitives and corresponding system-level optimizations, revealing a historical trend toward increased parallelism and memory bandwidth requirements. {#tbl-dl-evolution}
|
||||
|
||||
As we dive deeper into each of these building blocks, we see how these primitives evolved and combined to create increasingly powerful and complex neural network architectures.
|
||||
|
||||
@@ -1848,7 +1848,7 @@ To illustrate how these modern architectures synthesize and innovate upon previo
|
||||
| Data Movement | Broadcast | Sliding Window | Sequential | Broadcast + Gather |
|
||||
+----------------+-----------------------+----------------------------+-----------------------------+--------------------------+
|
||||
|
||||
: **Primitive Utilization**: Neural network architectures differ in their core computational and memory access patterns, impacting hardware requirements and efficiency. Transformers uniquely combine matrix multiplication with attention mechanisms, resulting in random memory access and data movement patterns distinct from sequential rnns or strided cnns. {#tbl-primitive-comparison .hover .striped}
|
||||
: **Primitive Utilization**: Neural network architectures differ in their core computational and memory access patterns, impacting hardware requirements and efficiency. Transformers uniquely combine matrix multiplication with attention mechanisms, resulting in random memory access and data movement patterns distinct from sequential rnns or strided cnns. {#tbl-primitive-comparison}
|
||||
|
||||
As shown in @tbl-primitive-comparison, Transformers combine elements from previous architectures while introducing new patterns. They retain the core matrix multiplication operations common to all architectures but introduce a more complex memory access pattern with their attention mechanism. Their data movement patterns blend the broadcast operations of MLPs with the gather operations reminiscent of more dynamic architectures.
|
||||
|
||||
@@ -2019,7 +2019,7 @@ These different memory access patterns contribute significantly to the overall m
|
||||
| Transformer | Quadratic | $O(N \times d)$ | $O(B \times N^2)$ | Problematic |
|
||||
+------------------+------------------+------------------------+--------------------------------------------------+------------------+
|
||||
|
||||
: **Memory Access Complexity**: Different neural network architectures exhibit varying memory access patterns and storage requirements, impacting system performance and scalability. Parameter storage scales with input dependency and model size, while activation storage represents a significant runtime cost, particularly for sequence-based models where rnns offer a parameter efficiency advantage when sequence length exceeds hidden state size ($n > h$). {#tbl-arch-complexity .hover .striped}
|
||||
: **Memory Access Complexity**: Different neural network architectures exhibit varying memory access patterns and storage requirements, impacting system performance and scalability. Parameter storage scales with input dependency and model size, while activation storage represents a significant runtime cost, particularly for sequence-based models where rnns offer a parameter efficiency advantage when sequence length exceeds hidden state size ($n > h$). {#tbl-arch-complexity}
|
||||
|
||||
Where:
|
||||
|
||||
@@ -2272,7 +2272,7 @@ The data movement primitives have particularly influenced the design of intercon
|
||||
| Gather/Scatter | High-bandwidth memory | Work distribution | Load balancing |
|
||||
+-----------------------+---------------------------+--------------------------+----------------------------+
|
||||
|
||||
: **Primitive-Hardware Co-Design**: Efficient machine learning systems require tight integration between algorithmic primitives and underlying hardware; this table maps common primitives to specific hardware accelerations and software optimizations, highlighting key challenges in their implementation. Specialized hardware, such as tensor cores and datapaths, address the computational demands of primitives like matrix multiplication and sliding windows, while software techniques like batching and dynamic graph execution further enhance performance. {#tbl-sys-design-implications .hover .striped}
|
||||
: **Primitive-Hardware Co-Design**: Efficient machine learning systems require tight integration between algorithmic primitives and underlying hardware; this table maps common primitives to specific hardware accelerations and software optimizations, highlighting key challenges in their implementation. Specialized hardware, such as tensor cores and datapaths, address the computational demands of primitives like matrix multiplication and sliding windows, while software techniques like batching and dynamic graph execution further enhance performance. {#tbl-sys-design-implications}
|
||||
|
||||
Despite these advancements, several common bottlenecks persist in deep learning systems. Memory bandwidth often remains a key limitation, particularly for models with large working sets or those that require frequent random access. The energy cost of data movement, especially between off-chip memory and processing units, continues to be a significant concern. For large-scale models, the communication overhead in distributed training can become a bottleneck, limiting scaling efficiency.
|
||||
|
||||
|
||||
@@ -568,7 +568,7 @@ These hybrid solutions aim to provide the flexibility of dynamic graphs during d
|
||||
| Deployment Complexity | Simpler deployment due to fixed structure | May require additional runtime support |
|
||||
+--------------------------------+-----------------------------------------------------------+-------------------------------------------------+
|
||||
|
||||
: **Graph Computation Modes**: Static graphs define the entire computation upfront, enabling optimization, while dynamic graphs construct the computation on-the-fly, offering flexibility for variable-length inputs and control flow. This distinction impacts both the efficiency of execution and the ease of model development and debugging. {#tbl-mlfm-graphs .hover .striped}
|
||||
: **Graph Computation Modes**: Static graphs define the entire computation upfront, enabling optimization, while dynamic graphs construct the computation on-the-fly, offering flexibility for variable-length inputs and control flow. This distinction impacts both the efficiency of execution and the ease of model development and debugging. {#tbl-mlfm-graphs}
|
||||
|
||||
### Automatic Differentiation {#sec-ai-frameworks-automatic-differentiation-6b16}
|
||||
|
||||
@@ -3388,7 +3388,7 @@ JAX introduces a set of composable function transformations that set it apart fr
|
||||
| Hardware Acceleration | CPU, GPU, TPU | CPU, GPU | CPU, GPU, TPU |
|
||||
+--------------------------+----------------------------------+-------------------+-----------------------------+
|
||||
|
||||
: **Framework Characteristics**: TensorFlow, PyTorch, and JAX differ in their graph construction—static, dynamic, or functional—which influences programming style and execution speed. Core distinctions include data mutability—arrays in JAX are immutable—and automatic differentiation capabilities, with JAX supporting both forward and reverse modes. {#tbl-mlfm-comparison .hover .striped}
|
||||
: **Framework Characteristics**: TensorFlow, PyTorch, and JAX differ in their graph construction—static, dynamic, or functional—which influences programming style and execution speed. Core distinctions include data mutability—arrays in JAX are immutable—and automatic differentiation capabilities, with JAX supporting both forward and reverse modes. {#tbl-mlfm-comparison}
|
||||
|
||||
## Framework Specialization {#sec-ai-frameworks-framework-specialization-acb6}
|
||||
|
||||
|
||||
@@ -343,7 +343,7 @@ The move to statistical approaches fundamentally changed how we think about buil
|
||||
| | | specific | | |
|
||||
+---------------------+--------------------------+--------------------------+--------------------------+-------------------------------+
|
||||
|
||||
: **AI Paradigm Evolution**: Shifting from symbolic AI to statistical approaches fundamentally changed machine learning by prioritizing data quantity and quality, enabling rigorous performance evaluation, and necessitating explicit trade-offs between precision and recall to optimize system behavior for specific applications. The table outlines how each paradigm addressed these challenges, revealing a progression towards data-driven systems capable of handling complex, real-world problems. {#tbl-ai-evolution-strengths .hover .striped}
|
||||
: **AI Paradigm Evolution**: Shifting from symbolic AI to statistical approaches fundamentally changed machine learning by prioritizing data quantity and quality, enabling rigorous performance evaluation, and necessitating explicit trade-offs between precision and recall to optimize system behavior for specific applications. The table outlines how each paradigm addressed these challenges, revealing a progression towards data-driven systems capable of handling complex, real-world problems. {#tbl-ai-evolution-strengths}
|
||||
|
||||
The table serves as a bridge between the early approaches we've discussed and the more recent developments in shallow and deep learning that we'll explore next. It sets the stage for understanding why certain approaches gained prominence in different eras and how each new paradigm built upon and addressed the limitations of its predecessors. Moreover, it illustrates how the strengths of earlier approaches continue to influence and enhance modern AI techniques, particularly in the era of foundation models.
|
||||
|
||||
|
||||
@@ -242,7 +242,7 @@ To better understand the dramatic differences between these ML deployment option
|
||||
| | | | | | | | motion detection |
|
||||
+---------------+-----------------------+--------------------------------------+----------------+------------------+-----------+-------------+--------------------------------+
|
||||
|
||||
: **Hardware Spectrum**: Machine learning system design necessitates trade-offs between computational resources, power consumption, and cost, as exemplified by the diverse hardware platforms suitable for cloud, edge, mobile, and TinyML deployments. This table quantifies those trade-offs, revealing how device capabilities—from high-end gpus in cloud servers to low-power microcontrollers in embedded systems—shape the types of models and tasks each platform can effectively support. Source: ABI Research -- Tiny ML. {#tbl-representative-systems .hover .striped}
|
||||
: **Hardware Spectrum**: Machine learning system design necessitates trade-offs between computational resources, power consumption, and cost, as exemplified by the diverse hardware platforms suitable for cloud, edge, mobile, and TinyML deployments. This table quantifies those trade-offs, revealing how device capabilities—from high-end gpus in cloud servers to low-power microcontrollers in embedded systems—shape the types of models and tasks each platform can effectively support. Source: ABI Research -- Tiny ML. {#tbl-representative-systems}
|
||||
|
||||
The evolution of machine learning systems can be seen as a progression from centralized to increasingly distributed and specialized computing paradigms:
|
||||
|
||||
@@ -1103,7 +1103,7 @@ The relationship between computational resources and deployment location forms o
|
||||
| Deployment Speed | Fast | Moderate | Fast | Slow |
|
||||
+--------------------------+----------------------------------------------------------+----------------------------------------------------------+-----------------------------------------------------------+----------------------------------------------------------+
|
||||
|
||||
: **Deployment Locations**: Machine learning systems vary in where computation occurs—from centralized cloud servers to local edge devices and ultra-low-power TinyML chips—each impacting latency, bandwidth, and energy consumption. This table categorizes these deployments by their processing location and associated characteristics, enabling informed decisions about system architecture and resource allocation. {#tbl-big_vs_tiny .hover .striped}
|
||||
: **Deployment Locations**: Machine learning systems vary in where computation occurs—from centralized cloud servers to local edge devices and ultra-low-power TinyML chips—each impacting latency, bandwidth, and energy consumption. This table categorizes these deployments by their processing location and associated characteristics, enabling informed decisions about system architecture and resource allocation. {#tbl-big_vs_tiny}
|
||||
|
||||
The operational characteristics of these systems reveal another important dimension of comparison. @tbl-big_vs_tiny organizes these characteristics into logical groupings, highlighting performance, operational considerations, costs, and development aspects. For instance, latency shows a clear gradient: cloud systems typically incur delays of 100-1000 ms due to network communication, while edge systems reduce this to 10-100 ms by processing data locally. Mobile ML achieves even lower latencies of 5-50 ms for many tasks, and TinyML systems can respond in 1-10 ms for simple inferences. Similarly, privacy and data handling improve progressively as computation shifts closer to the data source, with TinyML offering the strongest guarantees by keeping data entirely local to the device.
|
||||
|
||||
|
||||
@@ -839,7 +839,7 @@ These three approaches form a spectrum of tradeoffs. Their relative suitability
|
||||
| Sparse Layer Updates | Selective parameter subsets | Variable | High (task-adaptive) | Real-time adaptation; domain shift | Requires profiling or meta-training |
|
||||
+---------------------------+------------------------------+----------------------+-------------------------+----------------------------------------+-----------------------------------------+
|
||||
|
||||
: **Adaptation Strategy Trade-Offs**: Table entries characterize three approaches to model adaptation—bias-only updates, selective layer updates, and full finetuning—by quantifying their impact on trainable parameters, memory overhead, expressivity, suitability for different use cases, and system requirements. These characteristics reveal the inherent trade-offs between model flexibility, computational cost, and performance when deploying machine learning systems in dynamic environments. {#tbl-adaptation-strategies .striped .hover }
|
||||
: **Adaptation Strategy Trade-Offs**: Table entries characterize three approaches to model adaptation—bias-only updates, selective layer updates, and full finetuning—by quantifying their impact on trainable parameters, memory overhead, expressivity, suitability for different use cases, and system requirements. These characteristics reveal the inherent trade-offs between model flexibility, computational cost, and performance when deploying machine learning systems in dynamic environments. {#tbl-adaptation-strategies}
|
||||
|
||||
## Data Efficiency {#sec-ondevice-learning-data-efficiency-1cee}
|
||||
|
||||
@@ -1000,7 +1000,7 @@ Compressed data representations reduce the footprint of learning by transforming
|
||||
| | | | privacy-sensitive contexts|
|
||||
+-----------------------------+-----------------------------+----------------------------+---------------------------+
|
||||
|
||||
: **On-Device Learning Trade-Offs**: Few-shot adaptation balances data efficiency with model personalization by leveraging small labeled datasets, but requires careful consideration of memory and compute constraints for deployment on resource-limited devices. The table summarizes key considerations for selecting appropriate on-device learning techniques based on application requirements and available resources. {#tbl-ondevice-techniques .striped .hover }
|
||||
: **On-Device Learning Trade-Offs**: Few-shot adaptation balances data efficiency with model personalization by leveraging small labeled datasets, but requires careful consideration of memory and compute constraints for deployment on resource-limited devices. The table summarizes key considerations for selecting appropriate on-device learning techniques based on application requirements and available resources. {#tbl-ondevice-techniques}
|
||||
|
||||
In practice, these methods are not mutually exclusive. Many real-world systems combine them to achieve robust, efficient adaptation. For example, a keyword spotting system may use compressed audio features (e.g., MFCCs), finetune a few parameters from a small support set, and maintain a replay buffer of past embeddings for continual refinement.
|
||||
|
||||
|
||||
@@ -190,7 +190,7 @@ The key distinctions are summarized in @tbl-sw-ml-cycles below:
|
||||
| | | data preparation and model design. |
|
||||
+----------------------+------------------------------------------+--------------------------------------------------+
|
||||
|
||||
: **Traditional vs ML Development**: Traditional software and machine learning systems diverge in their development processes due to the data-driven and iterative nature of ML. Machine learning lifecycles emphasize experimentation and evolving objectives, requiring feedback loops between stages, whereas traditional software follows a linear progression with predefined specifications. {#tbl-sw-ml-cycles .hover .striped}
|
||||
: **Traditional vs ML Development**: Traditional software and machine learning systems diverge in their development processes due to the data-driven and iterative nature of ML. Machine learning lifecycles emphasize experimentation and evolving objectives, requiring feedback loops between stages, whereas traditional software follows a linear progression with predefined specifications. {#tbl-sw-ml-cycles}
|
||||
|
||||
These differences underline the need for a robust ML lifecycle framework that can accommodate iterative development, dynamic behavior, and data-driven decision-making. This lifecycle ensures that machine learning systems remain effective not only at launch but throughout their operational lifespan, even as environments evolve.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user