Add single-command GTL tuning matrix
This commit is contained in:
@@ -804,6 +804,47 @@ statistics, and portfolio results are unchanged. This closes the local
|
||||
backtest gate for the dual-purpose implementation. It does not itself authorize
|
||||
or perform a production deployment.
|
||||
|
||||
#### GTL tuning matrix
|
||||
|
||||
Exact parity establishes a safe, explicit control, but it does not prove that
|
||||
the inherited GTL constants are optimal. The `gtl_tuning` backtest arm exposes
|
||||
only those constants to an offline configuration; the live scanner continues
|
||||
to call the frozen default helper and cannot read this research configuration.
|
||||
|
||||
The single-command matrix contains 20 full-period arms. Each non-control arm
|
||||
changes exactly one input:
|
||||
|
||||
| Knob | Frozen control | Alternatives | Question isolated |
|
||||
|---|---:|---|---|
|
||||
| History | All available bars | 252 / 504 / 756 bars | Is recent or long-cycle range geometry useful? |
|
||||
| Candidate cap | 5 | 8 / unlimited | Does early pruning discard the useful headline? |
|
||||
| Max target distance | Existing volatility-dependent rule | 5.5 / 8 ATR universally | Is the medium-volatility unlimited branch the hidden edge? |
|
||||
| Traffic touch padding | 0.5% | 0 / 0.25% | Does padded price traffic carry information? |
|
||||
| Proposal merge | 0.5% | 0.25% / 1% | Is proposal density or consolidation important? |
|
||||
| Target zones | 2% | 1% / 3% | Does the reachable near edge manufacture the gate geometry? |
|
||||
| Range centers | 20 | 12 / 32 | Is coarse ladder density the useful feature? |
|
||||
| Pivots | Five-bar swings | None / eleven-bar swings | Do pivots add anything beyond the range ladder? |
|
||||
| Traffic strength scale | 500 | 250 / 1000 | Does strength saturation affect probability/selection? |
|
||||
|
||||
```bash
|
||||
.venv/bin/python scripts/run_gtl_tuning_matrix.py \
|
||||
backtest_snapshots/prod.sqlite --workers 14
|
||||
```
|
||||
|
||||
Arms execute sequentially so multiprocessing pools never compete. Each arm
|
||||
produces full-period production metrics, train/test books split at 2024-07-01,
|
||||
robust expectancy after removing the top 5% of setups, and retained/added/
|
||||
removed cohorts against control. The consolidated JSON and Markdown table are
|
||||
checkpointed after every arm; successful runs delete temporary per-arm reports
|
||||
unless `--keep-arm-reports` is set.
|
||||
|
||||
The pre-registered screen requires all of the following versus control:
|
||||
full/train/test Sharpe not worse, full-period drawdown not worse, at least 80%
|
||||
of production trades retained, and positive qualified expectancy after removing
|
||||
the top 5%. Passing identifies a candidate for forward paper validation, not an
|
||||
automatic deployment. The post-2024 interval has already influenced this
|
||||
research, so the split is a robustness check rather than a pristine holdout.
|
||||
|
||||
The post-2024 window has been opened and is now analysis data, not a valid final
|
||||
promotion holdout. These arms can isolate mechanism, but neither may ship without
|
||||
new future data or a separately pre-registered walk-forward protocol.
|
||||
|
||||
Reference in New Issue
Block a user