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>
|
||
| .. | ||
| GlobalEnums.mqh | ||
| InputEnums.mqh | ||
| README.md | ||
Enumerations Documentation
GlobalEnums.mqh
Defines the ENUM_SIGNAL enumeration for trading signal states:
Buy: Indicates a buy signal.Sell: Indicates a sell signal.Neutral: Indicates a neutral/no-action signal.Undefine: Indicates an undefined or uninitialized state.
InputEnums.mqh
Defines a large set of enumerations for configuration and input parameters used throughout the EA. These include:
- Custom menu and property enums for UI/configuration.
- Period presets (e.g., 5, 10, 14, 20, 30, 50, 100, 200) for indicator calculations.
- Training years presets for ML/AI training window selection.
- ATR multipliers for volatility-based calculations.
- Threshold presets for signal/trigger sensitivity.
- Risk/reward ratio presets for money management.
- Bars expiration settings for trade/session logic.
- Entry multipliers for order sizing.
- Trailing strategy types (none, ATR-based, SAR, MA, etc.).
- Money management strategies (fixed risk, intelligent, fixed lot, etc.).
- Day-of-week and session enums for time-based logic.
- ITF (Intraday Time Filter) settings.
- Hourly session presets (H1-H23) for time filtering.
Purpose: These enumerations provide a strongly-typed, maintainable way to configure and control the EA's behavior, supporting both traditional and AI/ML-driven logic. They enable dynamic feature selection, risk management, and strategy configuration, and are essential for modular, testable code.
Modernization Note:
- Enumerations should be referenced in configuration UIs and parameter files to enable dynamic, user-driven feature pipelines.
- Consider extending enums to support new AI/ML features and dynamic input selection as the EA evolves.