forked from animatedread/Warrior_EA
| Filename | Latest commit message | Latest commit date |
|---|---|---|
70cdec2717
FeedForwardConv emits POSITION-MAJOR output, matrix_o[out + window_out * i],
so one bar's window_out filter responses are contiguous and consecutive bars
sit window_out apart. Both pooling implementations (FeedForwardProof and
CPU_FeedForwardProof) slide FLAT over that buffer - pos = i * step, reducing
`window` CONSECUTIVE elements. On a position-major layout those neighbours
are different FILTERS of the same bar, never one filter across time.
At the shipped 3/2 the pool computed max(bar0_f0, bar0_f1, bar0_f2), then
max(bar0_f2, bar0_f3, bar0_f4), with every 8th window straddling a bar
boundary. So it collapsed unrelated feature detectors into whichever fired
hardest, passed gradient to that winner only, and halved the feature map
while doing it - all below every learnable layer, where nothing above can
recover it. The removed inputs' own labels ("3 Bars") show time-axis pooling
was the intent throughout.
Measured cost: CONV sat pinned at ~40% balanced accuracy for 510 eras with
Sell recall 0%, while plain MLPs on the same data reached 57-61%. HYBRID,
which also carried this stage, came second-worst of the batch-norm group.
Not fixable in the topology: pooling one filter across time needs a stride
of window_out BETWEEN samples within a window, which a consecutive-window
kernel cannot express at any window/step. That needs a stride-aware kernel
in Network.cl + WarriorCPU.cpp + WarriorDML.cpp and a DLL rebuild, and is
only worth doing if a conv front-end earns its place without downsampling
first - with 20 sliding positions there is little to gain by halving them.
ConvPoolWindow/ConvPoolStep and their enums are removed with it, along with
the |CP: fingerprint term added earlier today.
Both builds compile 0 errors, 0 warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
| .. | ||
| ConfidenceBridge.mqh | ||
| IndicatorResources.mqh | ||
| IndicatorTuneRanges.mqh | ||
| Inputs.mqh | ||
| README.md | ||
| 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.