forked from mnbvc188199/Warrior_EA
| Filename | Latest commit message | Latest commit date |
|---|---|---|
8ab8cf6b92
THRESHOLD. 40 is a measured correction, not a preference. Once RankTiersFromOos() replaced the designed tier priors with each model's real held-out win rate, the vote converges on that win rate - logged 2026-08-18 as pooled 23-36% across four members on three symbols - so a 50% bar could not be reached by anything on offer and the ensemble gate fired on 0 of 4,865 OOS bars. 40 clears the ~34% break-even those same lines report without being unreachable. The comment says plainly not to copy the number: break-even is a function of the barrier geometry, so read the gate's own "needs >N%" for the config in front of you. READOUT. One line, top-right: VOTE SELL 37.2% peak 44.1% need 40% 3 voter(s) -> no trade Every other number on the chart is downstream of the weighted mean the open threshold is compared against, and that was the one quantity never displayed. A chart with no arrows could mean the models abstained, the vote was diluted, or the threshold is unreachable - and telling those apart meant waiting for an era to end and reading the gate line, which is how the last two sessions went. PEAK is the part that earns its space. A threshold above what the vote ever attains can never fire, and that is not knowable from a single bar - it is precisely the "unreachable gate vs merely unmet gate" confusion this project has paid for twice. Colour carries the verdict rather than the direction: green/red ONLY when the vote would actually place an order, grey otherwise. Green-for-buy would make a below-threshold buy look like a trade, which is the specific misreading the display exists to prevent. Guarded on `total > 0` for the same reason the normalization is: Direction() is inherited as-is by every leaf filter, so without it each filter would write its own opinion into the one shared label and the last to run would win - the reader would be looking at an arbitrary member's number believing it was the vote. Drawn after the +-100 range check, so it shows what the threshold is actually tested against. CORNER_RIGHT_UPPER: the status lines, control panel and ensemble panel all live on the left. Registered in WarriorChartPrefixes() explicitly even though the "Warrior" catch-all already reaches it - that catch-all exists because the list has drifted twice, not to make entries optional. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| ConfidenceBridge.mqh | ||
| IndicatorResources.mqh | ||
| IndicatorTuneRanges.mqh | ||
| Inputs.mqh | ||
| README.md | ||
| RiskBudget.mqh | ||
| TunedPeriods.mqh | ||
| Variables.mqh | ||
Variables Subsystem (Variables/)
Overview
The Variables/ directory contains global input parameters and runtime variables for the Warrior EA. These files centralize configuration, feature toggles, and runtime state, supporting both user customization and internal logic.
Key Components
Inputs.mqh
- Purpose: Defines all user-configurable input parameters for the EA.
- Contents:
- General EA settings (magic number, training mode, logging, etc.)
- Money management strategy selection and parameters
- Entry strategy and thresholds
- Trailing stop strategy selection
- Neural network/AI configuration (algorithm, layers, training years, etc.)
- Indicator and feature toggles (enable/disable specific indicators and features)
- Time/session filter settings
- Integration: Used for both manual and programmatic configuration of the EA. Enables dynamic feature selection and AI/ML pipeline configuration.
Variables.mqh
- Purpose: Stores global runtime variables and constants.
- Contents:
- EA name and database schema
- Backtesting and feature enablement flags
- AI/ML signal toggles (EnablePAI, EnableCONV, EnableLSTM)
- Integration: Used throughout the EA for runtime logic, feature gating, and database operations.
Integration Notes
- Centralized configuration and variable management improves maintainability and supports advanced, AI/ML-driven workflows.
- Feature toggles allow for rapid experimentation and safe deployment of new logic.
Documented April 2026. For further details, see the main project documentation.