mirror of
https://github.com/MLSysBook/TinyTorch.git
synced 2026-04-30 22:56:55 -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/
5.5 KiB
5.5 KiB
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: []
Example: Breaking Down
Example: Breaking Down
📚 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 lines15_mlops/mlops_dev.py: 1,667 lines13_kernels/kernels_dev.py: 1,381 lines05_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.pyfile 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
# 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
- Bite-sized Learning: Students can master one concept at a time
- Natural Progression: Clear path through complex topics
- Better Testing: Each part can have focused inline tests
- Easier Review: Instructors can review specific components
- 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
02_tensor(1,578 lines) - Foundation module, affects all others15_mlops(1,667 lines) - Complex capstone module13_kernels(1,381 lines) - Performance engineering module11_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.