| Имя файла | Текст последнего коммита | Дата последнего коммита |
|---|---|---|
da54639996
The daily (4%) and total (8%) rules bound how FAST an account can lose. Nothing
noticed WHETHER it was losing. A negative-expectancy signal traded at 1% inside
that envelope breaches no rule and still arrives at zero - it just takes longer,
with every limit green the whole way down. That is the realistic way this EA
destroys an account, and no existing guard could see it.
THE ARITHMETIC THIS ENFORCES. Expected value per trade is p*TP - (1-p)*SL - cost.
With no directional edge p equals SL/(SL+TP), which is also the break-even rate,
so the payoff terms cancel exactly and EV = -cost. Expected P&L is -(trades) x
cost: strictly negative, proportional to activity. Measured here: directional
precision 23-24% against a 25% break-even, flat across every confidence tier,
with 58 points of spread on SP500. Sizing, stop placement and trailing move
variance around that mean; none of them changes its sign.
So every closed position now reports its result in R (net profit over money
actually at risk) and the running mean is tested against zero. Above the
configured minimum sample, if mean + sigma*SE < 0, new entries stop.
- SIGNIFICANTLY below, not merely below. A run of losers is ordinary variance
even for a profitable system; halting on the raw mean would be the same
act-on-noise error the MI gates exist to prevent. Using the standard error
means a wide spread simply demands more trades before the rule can fire.
- NET of swap and commission (ResolveClose already sums all three). Deliberate
and load-bearing: when the edge is zero, cost IS the expectancy, so a gross
version would measure a strategy nobody can trade.
- Reported in R so symbols, lot sizes and balances share one scale and one
mean. Trades without a stop are not scored rather than assigned a guessed R.
- LATCHED across restarts, like the daily halt and for the same reason: a
latch a reattach clears is not a latch. Clearing it means deleting the risk
state file, deliberately, after looking at why.
State is appended to the risk file length-guarded, so files written before this
still load and start their sample at zero rather than misreading.
Defaults 40 trades / 2 sigma; ExpectancyMinTrades = 0 disables it.
This does not make the strategy profitable and is not meant to. It stops paying
tuition on one the results say is losing, and does it on measurement rather than
on a drawdown limit finally being reached.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
| .. | ||
| ConfidenceBridge.mqh | ||
| IndicatorResources.mqh | ||
| IndicatorTuneRanges.mqh | ||
| Inputs.mqh | ||
| README.md | ||
| RiskBudget.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.