API Design¶
This document outlines the design principles and patterns used in TorchEBM's API, providing guidelines for contributors and insights for users building on top of the library.
API Design Philosophy¶
Design Goals
TorchEBM's API is designed with these goals in mind:
- Intuitive: APIs should be easy to understand and use
- Consistent: Similar operations should have similar interfaces
- Pythonic: Follow Python conventions and best practices
- Flexible: Allow for customization and extension
- Type-Safe: Use type hints for better IDE support and error checking
Core Abstractions¶
-
Energy Functions
Energy functions define the energy landscape that characterizes a probability distribution.
-
Samplers
Samplers generate samples from energy functions via various algorithms.
-
Loss Functions
BaseLoss functions are used to train energy-based models, often using samplers.
-
Models
Neural network models that can be used as energy functions.
Interface Design Patterns¶
Method Naming Conventions¶
TorchEBM follows consistent naming patterns:
Pattern | Example | Purpose |
---|---|---|
forward() |
energy_fn.forward(x) |
Core computation (energy) |
gradient() |
energy_fn.gradient(x) |
Compute gradients |
sample_chain() |
sampler.sample_chain(dim, n_steps) |
Generate samples |
step() |
sampler.step(x) |
Single sampling step |
Parameter Ordering¶
Parameters follow a consistent ordering pattern:
- Required parameters (e.g., input data, dimensions)
- Algorithm-specific parameters (e.g., step size, number of steps)
- Optional parameters with defaults (e.g., device, random seed)
Return Types¶
Return values are consistently structured:
- Single values are returned directly
- Multiple return values use tuples
- Complex returns use dictionaries for named access
- Diagnostic information is returned in a separate dictionary
Example:
Extension Patterns¶
Subclassing Base Classes¶
The primary extension pattern is to subclass the appropriate base class:
Composition Pattern¶
For more complex extensions, composition can be used:
Configuration and Customization¶
Constructor Parameters¶
Features are enabled and configured primarily through constructor parameters:
Method Parameters¶
Runtime behavior is controlled through method parameters:
Handling Errors and Edge Cases¶
TorchEBM follows these practices for error handling:
- Input Validation: Validate inputs early and raise descriptive exceptions
- Graceful Degradation: Fall back to simpler algorithms when necessary
- Informative Exceptions: Provide clear error messages with suggestions
- Default Safety: Choose safe default values that work in most cases
Example:
API Evolution Guidelines¶
When evolving the API, we follow these guidelines:
- Backward Compatibility: Avoid breaking changes when possible
- Deprecation Cycle: Use deprecation warnings before removing features
- Default Arguments: Add new parameters with sensible defaults
- Feature Flags: Use boolean flags to enable/disable new features
Example of deprecation:
Documentation Standards¶
All APIs should include:
- Docstrings for all public classes and methods
- Type hints for parameters and return values
- Examples showing common usage patterns
- Notes on performance implications
- References to relevant papers or algorithms
Example:
By following these API design principles, TorchEBM maintains a consistent, intuitive, and extensible interface for energy-based modeling in PyTorch.