mirror of
https://github.com/MLSysBook/TinyTorch.git
synced 2026-07-21 20:44:04 -05:00
Vijay Janapa Reddi
791d1e3153
- Regenerate all .ipynb files from fixed .py modules - Update tinytorch package exports with corrected implementations - Sync package module index with current 16-module structure These generated files reflect all the module fixes and ensure consistent .py ↔ .ipynb conversion with the updated module implementations.
46 KiB
46 KiB
In [ ]:
#| default_exp core.setup
#| export
import sys
import platform
import psutil
from typing import Dict, AnyIn [ ]:
print("🔥 TinyTorch Setup Module")
print(f"Python version: {sys.version_info.major}.{sys.version_info.minor}")
print(f"Platform: {platform.system()}")
print("Ready to configure your TinyTorch installation!")In [ ]:
#| export
def personal_info() -> Dict[str, str]:
"""
Return personal information for this TinyTorch installation.
This function configures your personal TinyTorch installation with your identity.
It's the foundation of proper ML engineering practices - every system needs
to know who built it and how to contact them.
TODO: Implement personal information configuration.
STEP-BY-STEP IMPLEMENTATION:
1. Create a dictionary with your personal details
2. Include all required keys: developer, email, institution, system_name, version
3. Use your actual information (not placeholder text)
4. Make system_name unique and descriptive
5. Keep version as '1.0.0' for now
EXAMPLE USAGE:
```python
# Get your personal configuration
info = personal_info()
print(info['developer']) # Expected: "Your Name" (not placeholder)
print(info['email']) # Expected: "you@domain.com" (valid email)
print(info['system_name']) # Expected: "YourName-Dev" (unique identifier)
print(info) # Expected: Complete dict with 5 fields
# Output: {
# 'developer': 'Your Name',
# 'email': 'you@domain.com',
# 'institution': 'Your Institution',
# 'system_name': 'YourName-TinyTorch-Dev',
# 'version': '1.0.0'
# }
```
IMPLEMENTATION HINTS:
- Replace the example with your real information
- Use a descriptive system_name (e.g., 'YourName-TinyTorch-Dev')
- Keep email format valid (contains @ and domain)
- Make sure all values are strings
- Consider how this info will be used in debugging and collaboration
LEARNING CONNECTIONS:
- This is like the 'author' field in Git commits
- Similar to maintainer info in Docker images
- Parallels author info in Python packages
- Foundation for professional ML development
"""
### BEGIN SOLUTION
return {
'developer': 'Student Name',
'email': 'student@university.edu',
'institution': 'University Name',
'system_name': 'StudentName-TinyTorch-Dev',
'version': '1.0.0'
}
### END SOLUTIONIn [ ]:
def test_unit_personal_info_basic():
"""Test personal_info function implementation."""
print("🔬 Unit Test: Personal Information...")
# Test personal_info function
personal = personal_info()
# Test return type
assert isinstance(personal, dict), "personal_info should return a dictionary"
# Test required keys
required_keys = ['developer', 'email', 'institution', 'system_name', 'version']
for key in required_keys:
assert key in personal, f"Dictionary should have '{key}' key"
# Test non-empty values
for key, value in personal.items():
assert isinstance(value, str), f"Value for '{key}' should be a string"
assert len(value) > 0, f"Value for '{key}' cannot be empty"
# Test email format
assert '@' in personal['email'], "Email should contain @ symbol"
assert '.' in personal['email'], "Email should contain domain"
# Test version format
assert personal['version'] == '1.0.0', "Version should be '1.0.0'"
# Test system name (should be unique/personalized)
assert len(personal['system_name']) > 5, "System name should be descriptive"
print("✅ Personal info function tests passed!")
print(f"✅ TinyTorch configured for: {personal['developer']}")
# Test function defined (called in main block)In [ ]:
#| export
def system_info() -> Dict[str, Any]:
"""
Query and return system information for this TinyTorch installation.
This function gathers crucial hardware and software information that affects
ML performance, compatibility, and debugging. It's the foundation of
hardware-aware ML systems.
TODO: Implement system information queries.
STEP-BY-STEP IMPLEMENTATION:
1. Get Python version using sys.version_info
2. Get platform using platform.system()
3. Get architecture using platform.machine()
4. Get CPU count using psutil.cpu_count()
5. Get memory using psutil.virtual_memory().total
6. Convert memory from bytes to GB (divide by 1024^3)
7. Return all information in a dictionary
EXAMPLE USAGE:
```python
# Query system information
sys_info = system_info()
print(f"Python: {sys_info['python_version']}") # Expected: "3.x.x"
print(f"Platform: {sys_info['platform']}") # Expected: "Darwin"/"Linux"/"Windows"
print(f"CPUs: {sys_info['cpu_count']}") # Expected: 4, 8, 16, etc.
print(f"Memory: {sys_info['memory_gb']} GB") # Expected: 8.0, 16.0, 32.0, etc.
# Full output example:
print(sys_info)
# Expected: {
# 'python_version': '3.9.7',
# 'platform': 'Darwin',
# 'architecture': 'arm64',
# 'cpu_count': 8,
# 'memory_gb': 16.0
# }
```
IMPLEMENTATION HINTS:
- Use f-string formatting for Python version: f"{major}.{minor}.{micro}"
- Memory conversion: bytes / (1024^3) = GB
- Round memory to 1 decimal place for readability
- Make sure data types are correct (strings for text, int for cpu_count, float for memory_gb)
LEARNING CONNECTIONS:
- This is like `torch.cuda.is_available()` in PyTorch
- Similar to system info in MLflow experiment tracking
- Parallels hardware detection in TensorFlow
- Foundation for performance optimization in ML systems
PERFORMANCE IMPLICATIONS:
- cpu_count affects parallel processing capabilities
- memory_gb determines maximum model and batch sizes
- platform affects file system and process management
- architecture influences numerical precision and optimization
"""
### BEGIN SOLUTION
# Get Python version
version_info = sys.version_info
python_version = f"{version_info.major}.{version_info.minor}.{version_info.micro}"
# Get platform information
platform_name = platform.system()
architecture = platform.machine()
# Get CPU information
cpu_count = psutil.cpu_count()
# Get memory information (convert bytes to GB)
memory_bytes = psutil.virtual_memory().total
memory_gb = round(memory_bytes / (1024**3), 1)
return {
'python_version': python_version,
'platform': platform_name,
'architecture': architecture,
'cpu_count': cpu_count,
'memory_gb': memory_gb
}
### END SOLUTIONIn [ ]:
def test_unit_system_info_basic():
"""Test system_info function implementation."""
print("🔬 Unit Test: System Information...")
# Test system_info function
sys_info = system_info()
# Test return type
assert isinstance(sys_info, dict), "system_info should return a dictionary"
# Test required keys
required_keys = ['python_version', 'platform', 'architecture', 'cpu_count', 'memory_gb']
for key in required_keys:
assert key in sys_info, f"Dictionary should have '{key}' key"
# Test data types
assert isinstance(sys_info['python_version'], str), "python_version should be string"
assert isinstance(sys_info['platform'], str), "platform should be string"
assert isinstance(sys_info['architecture'], str), "architecture should be string"
assert isinstance(sys_info['cpu_count'], int), "cpu_count should be integer"
assert isinstance(sys_info['memory_gb'], (int, float)), "memory_gb should be number"
# Test reasonable values
assert sys_info['cpu_count'] > 0, "CPU count should be positive"
assert sys_info['memory_gb'] > 0, "Memory should be positive"
assert len(sys_info['python_version']) > 0, "Python version should not be empty"
# Test that values are actually queried (not hardcoded)
actual_version = f"{sys.version_info.major}.{sys.version_info.minor}.{sys.version_info.micro}"
assert sys_info['python_version'] == actual_version, "Python version should match actual system"
print("✅ System info function tests passed!")
print(f"✅ Python: {sys_info['python_version']} on {sys_info['platform']}")In [ ]:
"""
YOUR REFLECTION ON TEAM DEVELOPMENT CONFIGURATION:
TODO: Replace this text with your thoughtful response about designing configuration systems for team-based ML development.
Consider addressing:
- How would you maintain individual identity while enabling team coordination?
- What information would be shared vs. personal in a team configuration system?
- How would you handle resource conflicts when multiple developers need GPU access?
- What role would configuration play in debugging issues across team environments?
- How might team configuration differ from individual configuration?
Write a thoughtful analysis connecting your setup module experience to real team challenges.
GRADING RUBRIC (Instructor Use):
- Demonstrates understanding of individual vs team configuration needs (3 points)
- Addresses resource sharing and conflict resolution challenges (3 points)
- Connects setup module concepts to real team scenarios (2 points)
- Shows systems thinking about scalability and coordination (2 points)
- Clear writing and practical insights (bonus points for exceptional responses)
"""
### BEGIN SOLUTION
# Student response area - instructor will replace this section during grading setup
# This is a manually graded question requiring thoughtful analysis of team configuration challenges
# Students should demonstrate understanding of balancing individual accountability with team coordination
### END SOLUTIONIn [ ]:
"""
YOUR REFLECTION ON HARDWARE-AWARE SYSTEM DESIGN:
TODO: Replace this text with your thoughtful response about hardware-aware configuration systems.
Consider addressing:
- How would your system automatically adapt training parameters based on detected hardware?
- What would you do differently for development vs. training vs. inference environments?
- How would you handle memory constraints and batch size optimization automatically?
- What configuration decisions should be automated vs. left to manual tuning?
- How would your system gracefully handle resource limitations?
Write a practical design connecting your system_info() implementation to real performance challenges.
GRADING RUBRIC (Instructor Use):
- Shows understanding of hardware constraints impact on ML performance (3 points)
- Designs practical automated adaptation strategies (3 points)
- Addresses different deployment environments appropriately (2 points)
- Demonstrates systems thinking about resource optimization (2 points)
- Clear design reasoning and practical considerations (bonus points for innovative approaches)
"""
### BEGIN SOLUTION
# Student response area - instructor will replace this section during grading setup
# This is a manually graded question requiring design thinking about hardware-aware systems
# Students should demonstrate understanding of automatic adaptation based on hardware detection
### END SOLUTIONIn [ ]:
"""
YOUR REFLECTION ON PRODUCTION ML PIPELINE CONFIGURATION:
TODO: Replace this text with your thoughtful response about configuration in production ML systems.
Consider addressing:
- How would configuration information become part of model lineage and audit trails?
- What configuration would be bundled with the model vs. environment-specific?
- How would your configuration system support A/B testing and deployment strategies?
- What role would configuration play in monitoring and debugging production issues?
- How would compliance requirements (data governance, model validation) affect configuration design?
Write an analysis connecting your setup module concepts to MLOps and production deployment challenges.
GRADING RUBRIC (Instructor Use):
- Understands configuration role in model lineage and compliance (3 points)
- Addresses model artifact vs. environment configuration separation (3 points)
- Shows awareness of MLOps integration challenges (2 points)
- Demonstrates production systems thinking (2 points)
- Clear analysis with practical MLOps insights (bonus points for deep understanding)
"""
### BEGIN SOLUTION
# Student response area - instructor will replace this section during grading setup
# This is a manually graded question requiring understanding of production ML configuration challenges
# Students should demonstrate understanding of configuration in MLOps and production deployment contexts
### END SOLUTION