Files
optimiz-rs/docs/ENHANCEMENT_STRATEGY.md
T

408 lines
12 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# OptimizR Enhancement Strategy
**Date**: January 2, 2025
**Context**: Post-Polarway Phase 4, exploring integration and improvements
**Based On**: v0.2.0 codebase review, roadmap analysis, synergy opportunities
## Current State Analysis
### ✅ What's Implemented (v0.2.0)
1. **Core Algorithms**:
- Differential Evolution (5 strategies: rand1, best1, currenttobest1, rand2, best2)
- Hidden Markov Models (Baum-Welch, Viterbi)
- MCMC Sampling (Metropolis-Hastings, adaptive proposals)
- Grid Search
- Information Theory (mutual information, Shannon entropy)
2. **Advanced Features (v0.2.0)**:
- Sparse Optimization (Sparse PCA, Box-Tao, Elastic Net)
- Optimal Control (HJB solver, regime switching, jump diffusion)
- Risk Metrics (Hurst exponent, half-life, bootstrap)
- Mathematical Toolkit (numerical differentiation, linear algebra, statistics)
3. **Architecture**:
- Trait-based design (Optimizer, Sampler, InformationMeasure)
- Builder pattern for configuration
- Functional programming utilities (composition, memoization, pipes)
- Rayon dependency already present
- Feature flag infrastructure (`parallel` feature exists)
### ⚠️ What's Missing/Incomplete
1. **Parallelization BLOCKED**:
- Infrastructure exists (Rayon trait, ParallelExecutor trait in core.rs)
- DE has `parallel` parameter but **disabled** due to Python GIL
- Comment: "Python callbacks cannot be safely parallelized due to GIL"
- Grid search marked as "future: Expected 50-100x speedup"
2. **Advanced DE Variants (Roadmap v0.3.0)**:
- JADE (jDE with archive)
- SHADE (Success-History based Adaptive DE)
- L-SHADE (with linear population reduction)
- Current: Only basic jDE adaptive control
3. **Multi-Objective Optimization (Roadmap)**:
- NSGA-DE (Non-dominated Sorting)
- MODE (Multi-Objective DE)
- Pareto front computation
4. **GPU Acceleration (Roadmap)**:
- CUDA kernels
- OpenCL support
- 10-100× additional speedup
5. **Additional Algorithms (Roadmap)**:
- Particle Swarm Optimization (PSO)
- CMA-ES (Covariance Matrix Adaptation)
- Simulated Annealing
- Ant Colony Optimization
## Synergy Opportunities: Polarway + OptimizR
### 1. Time-Series Feature Engineering for HMM
**Description**: Use Polarway's time-series operations to create features for regime detection
**Implementation**:
```python
# Polarway: Fast feature creation
df = client.lag(['price'], periods=1) # Lagged prices
df = client.pct_change(['price'], periods=1) # Returns
df = client.diff(['price'], periods=1) # Price changes
# OptimizR: Regime detection on features
returns = df['price_pct_change'].to_numpy()
hmm = HMM(n_states=3) # Bull, Bear, Sideways
hmm.fit(returns, n_iterations=100)
states = hmm.predict(returns)
```
**Value**:
- Polarway provides fast feature engineering (50-200× faster for large datasets)
- OptimizR provides statistical inference (HMM regime detection)
- Combined: Real-time regime switching for trading strategies
### 2. Risk Metrics on Time-Series Data
**Description**: Calculate advanced risk metrics using both systems
**Implementation**:
```python
# Polarway: Efficient return calculation
df = client.pct_change(['price'], periods=1)
returns = df['price_pct_change'].to_numpy()
# OptimizR: Risk analysis
hurst = compute_hurst_exponent(returns) # Mean-reversion detection
half_life = estimate_half_life(returns) # Reversion time
risk_metrics = compute_risk_metrics(returns) # Comprehensive suite
```
**Value**:
- Fast preprocessing (Polarway) + sophisticated analysis (OptimizR)
- Useful for pairs trading, mean-reversion strategies
- Real-time risk monitoring
### 3. Optimal Control with Market Data
**Description**: Dynamic portfolio rebalancing with regime-dependent strategies
**Implementation**:
```python
# Polarway: Multi-asset feature creation
df = client.lag(['spy_price', 'vix'], periods=[1, 5, 20])
df = client.pct_change(['spy_price'], periods=1)
# OptimizR: Solve optimal control problem
# State: [price, volatility regime]
# Control: portfolio weights
value_fn = solve_hjb_regime_switching(...)
```
**Value**:
- Combines fast data processing with optimal control theory
- Regime-dependent strategies (bull vs bear market)
- Practical for HFT and algorithmic trading
### 4. Parameter Optimization for Trading Strategies
**Description**: Use DE to optimize strategy parameters on time-series data
**Implementation**:
```python
# Polarway: Backtest execution (fast data ops)
def backtest_strategy(params):
df = client.lag(['price'], periods=int(params[0]))
# ... strategy logic ...
return -sharpe_ratio # Minimize negative Sharpe
# OptimizR: Find optimal parameters
result = differential_evolution(
objective_fn=backtest_strategy,
bounds=[(1, 50), (0.01, 0.5)], # [lag_period, threshold]
maxiter=500,
strategy='rand1'
)
```
**Value**:
- Polarway handles heavy data processing
- OptimizR finds optimal parameters
- 74-88× faster than SciPy DE
## High-Priority Enhancements
### Priority 1: Enable Parallelization for Pure-Rust Objectives
**Problem**: `parallel` parameter exists but disabled due to Python GIL issues
**Solution**: Create Rust-native objective function trait for GIL-free parallelization
**Implementation Strategy**:
1. Add `RustObjectiveFn` trait separate from Python callbacks
2. Implement parallel evaluation for Rust-native functions
3. Keep Python callbacks sequential (GIL limitation)
4. Enable parallel grid search (no Python callbacks needed for grid)
**Code Outline**:
```rust
// In src/core.rs or src/differential_evolution.rs
/// Rust-native objective function (no Python, no GIL)
pub trait RustObjective: Send + Sync {
fn evaluate(&self, x: &[f64]) -> f64;
}
/// Parallel evaluation for Rust objectives
#[cfg(feature = "parallel")]
fn evaluate_population_parallel<F: RustObjective>(
objective: &F,
population: &[Vec<f64>]
) -> Vec<f64> {
use rayon::prelude::*;
population.par_iter()
.map(|individual| objective.evaluate(individual))
.collect()
}
// Python binding for benchmarking
#[pyfunction]
fn differential_evolution_rust(
objective_name: &str, // "sphere", "rosenbrock", "rastrigin"
bounds: Vec<(f64, f64)>,
parallel: bool, // Now actually works!
...
) -> PyResult<DEResult>
```
**Benefits**:
- 10-100× speedup for built-in test functions (sphere, Rosenbrock, Rastrigin)
- Useful for benchmarking and testing
- Grid search can be parallelized (no callbacks)
- Foundation for future Rust-only mode
**Effort**: Medium (1-2 hours)
### Priority 2: Implement SHADE (Success-History Adaptive DE)
**Problem**: Current adaptive DE uses basic jDE, SHADE is state-of-the-art
**Solution**: Implement SHADE algorithm from Tanabe & Fukunaga (2013)
**Key Features**:
- Historical memory of successful parameters (F, CR)
- Weighted random selection from memory
- Better than jDE on CEC benchmarks
**Implementation Strategy**:
1. Add `SHADE` variant to `DEStrategy` enum
2. Create success history buffer (circular buffer of size H=10-100)
3. Update memory after each successful mutation
4. Sample (F, CR) from history using Cauchy/Normal distributions
**Code Outline**:
```rust
pub enum DEAdaptive {
None,
JDE, // Current implementation
SHADE, // New: Success-history based
LSHADE, // Future: With linear population reduction
}
struct SHADEMemory {
history_f: Vec<f64>, // Successful F values
history_cr: Vec<f64>, // Successful CR values
index: usize, // Circular buffer index
size: usize, // Memory size H
}
impl SHADEMemory {
fn sample_f(&self) -> f64 {
// Cauchy distribution centered on random history entry
}
fn sample_cr(&self) -> f64 {
// Normal distribution centered on random history entry
}
fn update(&mut self, successful_f: f64, successful_cr: f64) {
// Add to circular buffer
}
}
```
**Benefits**:
- State-of-the-art adaptive control
- Better than jDE empirically
- Aligns with roadmap (v0.3.0)
- Minimal API changes
**Effort**: Medium-High (2-4 hours with testing)
### Priority 3: Time-Series Integration Helpers
**Problem**: Using Polarway + OptimizR requires manual glue code
**Solution**: Create helper functions for common time-series + optimization patterns
**Implementation Strategy**:
1. Add `timeseries_utils` module to OptimizR
2. Functions for common workflows
3. Optional Polarway integration (via feature flag)
**Code Outline**:
```rust
// New module: src/timeseries_utils.rs
/// Prepare time-series data for HMM regime detection
pub fn prepare_for_hmm(
prices: &[f64],
lag_periods: &[usize],
) -> Vec<Vec<f64>> {
// Create features: returns, lagged returns, etc.
}
/// Rolling window risk metrics
pub fn rolling_hurst_exponent(
returns: &[f64],
window_size: usize,
) -> Vec<f64> {
// Compute Hurst exponent in rolling windows
}
/// Backtest parameter optimization
pub fn optimize_strategy_params<F>(
objective_fn: F,
param_bounds: Vec<(f64, f64)>,
n_trials: usize,
) -> DEResult
where F: Fn(&[f64]) -> f64
{
// Wrapper around DE with sensible defaults
}
```
**Python Bindings**:
```python
from optimizr import timeseries_utils as tsu
# Prepare features
features = tsu.prepare_for_hmm(prices, lag_periods=[1, 5, 20])
# Rolling risk metrics
rolling_hurst = tsu.rolling_hurst_exponent(returns, window_size=252)
# Strategy optimization
def my_strategy(params):
# ... backtesting logic ...
return sharpe_ratio
result = tsu.optimize_strategy_params(
my_strategy,
param_bounds=[(1, 50), (0.01, 0.5)],
n_trials=500
)
```
**Benefits**:
- Reduces boilerplate for common use cases
- Makes integration obvious
- Encourages adoption
- Low effort, high value
**Effort**: Low-Medium (1-2 hours)
## Secondary Enhancements (Future Work)
### 4. Multi-Objective Optimization (NSGA-DE)
- **Roadmap**: v0.3.0
- **Use Case**: Portfolio optimization (maximize return, minimize risk)
- **Effort**: High (5-8 hours)
### 5. GPU Acceleration
- **Roadmap**: v0.3.0
- **Use Case**: Massive population sizes (10K-100K individuals)
- **Effort**: Very High (multi-day project)
### 6. Additional Algorithms (PSO, CMA-ES, etc.)
- **Roadmap**: v0.3.0
- **Use Case**: Algorithm portfolio for different problem types
- **Effort**: High per algorithm (3-5 hours each)
## Recommended Implementation Order
1. **Session 1 (Current)**: Time-Series Integration Helpers (1-2 hours)
- Low effort, immediate value
- Makes Polarway + OptimizR integration obvious
- Creates examples for documentation
2. **Session 2**: Enable Rust-Native Parallelization (1-2 hours)
- Unblocks major performance gain
- Grid search parallelization
- Foundation for future work
3. **Session 3**: Implement SHADE (2-4 hours)
- State-of-the-art adaptive DE
- Aligns with roadmap
- Publishable improvement
4. **Future**: Multi-objective, GPU, additional algorithms
- Larger projects
- Requires more research
## Testing Strategy
For each enhancement:
1. **Unit tests**: Algorithm correctness (sphere function, Rosenbrock)
2. **Benchmarks**: Performance comparison (before/after)
3. **Integration tests**: Polarway + OptimizR workflows
4. **Documentation**: Usage examples, API docs
## Git Commit Strategy (per MANDATORY rules)
Each enhancement gets:
1. Feature branch: `feature/shade-algorithm` or `feature/rust-parallelization`
2. Implementation commits with tests
3. Benchmark results documented
4. Final commit: `feat(de): implement SHADE adaptive DE variant`
5. Push to origin
6. Log to historia/
## Success Metrics
1. **Performance**:
- Rust parallelization: 10-100× speedup on multi-core
- SHADE: 10-20% better convergence than jDE on benchmarks
- Time-series helpers: Zero overhead (pure convenience)
2. **Usability**:
- Integration examples in documentation
- Clear API documentation
- Python usage examples
3. **Completeness**:
- All tests passing
- Benchmarks documented
- Changes committed to git
---
**Next Action**: Implement Priority 3 (Time-Series Integration Helpers) as it's lowest effort with immediate value for demonstrating Polarway + OptimizR synergy.