mirror of
https://github.com/MLSysBook/TinyTorch.git
synced 2026-05-01 00:38:35 -05:00
Documentation updates across the codebase: Root documentation: - README.md: Updated references from book/ to site/ - CONTRIBUTING.md: Updated build and workflow instructions - .shared-ai-rules.md: Updated AI assistant rules for new structure GitHub configuration: - Issue templates updated for new module locations - Workflow references updated from book/ to site/ docs/ updates: - STUDENT_QUICKSTART.md: New paths and structure - module-rules.md: Updated module development guidelines - NBGrader documentation: Updated for module restructuring - Archive documentation: Updated references Module documentation: - modules/17_memoization/README.md: Updated after reordering All documentation now correctly references: - site/ instead of book/ - modules/XX_name/ instead of modules/source/
147 lines
5.5 KiB
Markdown
147 lines
5.5 KiB
Markdown
---
|
|
name: 📚 Module Architecture: Break Complex Modules into Digestible Sub-Components
|
|
about: Suggest breaking down large monolithic modules into smaller, focused pieces while maintaining educational cohesion
|
|
title: "Break [MODULE_NAME] into smaller sub-components while maintaining module unity"
|
|
labels: ["enhancement", "education", "architecture", "modules"]
|
|
assignees: []
|
|
---
|
|
|
|
## 📚 **Educational Problem**
|
|
|
|
Several TinyTorch modules have grown quite large (1000+ lines), making them difficult for students to navigate, understand, and debug. While the modules work well as cohesive educational units, the individual development files can be overwhelming.
|
|
|
|
**Current Complex Modules:**
|
|
- `02_tensor/tensor_dev.py`: 1,578 lines
|
|
- `15_mlops/mlops_dev.py`: 1,667 lines
|
|
- `13_kernels/kernels_dev.py`: 1,381 lines
|
|
- `05_dense/dense_dev.py`: 907 lines
|
|
|
|
## 🎯 **Proposed Solution**
|
|
|
|
Break each complex module into **smaller, focused sub-components** while maintaining the module structure and educational flow. Think "bite-sized pieces that still work as a whole."
|
|
|
|
### Example: Breaking Down `02_tensor` Module
|
|
|
|
**Current Structure:**
|
|
```
|
|
modules/02_tensor/
|
|
├── tensor_dev.py # 1,578 lines - everything in one file
|
|
├── module.yaml
|
|
└── README.md
|
|
```
|
|
|
|
**Proposed Structure:**
|
|
```
|
|
modules/02_tensor/
|
|
├── parts/
|
|
│ ├── 01_foundations.py # Mathematical foundations & tensor theory
|
|
│ ├── 02_creation.py # Tensor creation & initialization
|
|
│ ├── 03_operations.py # Core arithmetic operations
|
|
│ ├── 04_broadcasting.py # Broadcasting & shape manipulation
|
|
│ ├── 05_advanced.py # Advanced operations & edge cases
|
|
│ └── 06_integration.py # Integration tests & complete examples
|
|
├── tensor_dev.py # Main orchestrator that imports all parts
|
|
├── module.yaml
|
|
└── README.md
|
|
```
|
|
|
|
### Example: Breaking Down `15_mlops` Module
|
|
|
|
**Current Structure:**
|
|
```
|
|
modules/15_mlops/
|
|
├── mlops_dev.py # 1,667 lines - entire MLOps pipeline
|
|
├── module.yaml
|
|
└── README.md
|
|
```
|
|
|
|
**Proposed Structure:**
|
|
```
|
|
modules/15_mlops/
|
|
├── parts/
|
|
│ ├── 01_monitoring.py # Model and data drift detection
|
|
│ ├── 02_deployment.py # Model serving & API endpoints
|
|
│ ├── 03_pipeline.py # Continuous learning workflows
|
|
│ ├── 04_registry.py # Model versioning & registry
|
|
│ ├── 05_alerting.py # Alert systems & notifications
|
|
│ └── 06_integration.py # Full MLOps pipeline integration
|
|
├── mlops_dev.py # Main orchestrator
|
|
├── module.yaml
|
|
└── README.md
|
|
```
|
|
|
|
## 🏗️ **Implementation Strategy**
|
|
|
|
### 1. **Maintain Module Unity**
|
|
- Keep the main `{module}_dev.py` file as the **primary entry point**
|
|
- Use imports to bring all sub-components together
|
|
- Ensure the module still "feels like one cohesive lesson"
|
|
|
|
### 2. **Logical Decomposition**
|
|
- Break modules by **conceptual boundaries**, not arbitrary line counts
|
|
- Each sub-component should be **self-contained** but **integrate seamlessly**
|
|
- Maintain the **Build → Use → Optimize** educational flow across parts
|
|
|
|
### 3. **Educational Benefits**
|
|
- **Easier navigation**: Students can focus on specific concepts
|
|
- **Better debugging**: Smaller files are easier to troubleshoot
|
|
- **Clearer progression**: Natural learning checkpoints within modules
|
|
- **Maintained cohesion**: Everything still works together as intended
|
|
|
|
### 4. **Technical Implementation**
|
|
```python
|
|
# Main module file (e.g., tensor_dev.py)
|
|
"""
|
|
TinyTorch Tensor Module - Complete Implementation
|
|
Students work through parts/ directory, then see integration here.
|
|
"""
|
|
|
|
# Import all sub-components
|
|
from .parts.foundations import *
|
|
from .parts.creation import *
|
|
from .parts.operations import *
|
|
from .parts.broadcasting import *
|
|
from .parts.advanced import *
|
|
|
|
# Integration and final examples
|
|
from .parts.integration import run_complete_tensor_demo
|
|
|
|
# Expose the complete Tensor class
|
|
__all__ = ['Tensor', 'run_complete_tensor_demo']
|
|
```
|
|
|
|
## 🎓 **Educational Advantages**
|
|
|
|
1. **Bite-sized Learning**: Students can master one concept at a time
|
|
2. **Natural Progression**: Clear path through complex topics
|
|
3. **Better Testing**: Each part can have focused inline tests
|
|
4. **Easier Review**: Instructors can review specific components
|
|
5. **Maintained Flow**: Module still tells one coherent story
|
|
|
|
## 🔧 **Implementation Notes**
|
|
|
|
- This is **architectural improvement**, not feature addition
|
|
- Maintains all existing functionality and educational goals
|
|
- **Backward compatible**: Current workflows continue to work
|
|
- Each module can be migrated independently
|
|
- Priority should be given to largest/most complex modules first
|
|
|
|
## 📋 **Success Criteria**
|
|
|
|
- [ ] No single sub-component exceeds ~300 lines
|
|
- [ ] Each part has clear educational purpose
|
|
- [ ] Main module file remains functional entry point
|
|
- [ ] All inline tests continue to pass
|
|
- [ ] Students report improved navigation and understanding
|
|
- [ ] Module still "feels like one lesson" despite internal structure
|
|
|
|
## 🎯 **Priority Modules for Migration**
|
|
|
|
1. **`02_tensor`** (1,578 lines) - Foundation module, affects all others
|
|
2. **`15_mlops`** (1,667 lines) - Complex capstone module
|
|
3. **`13_kernels`** (1,381 lines) - Performance engineering module
|
|
4. **`11_training`** (estimated 1,000+ lines) - Core training pipeline
|
|
|
|
---
|
|
|
|
**This enhancement will make TinyTorch more student-friendly while maintaining its educational integrity and systematic learning progression.** |