Warrior_EA/SIGNALS.md
AnimateDread 8157c42314 feat: Enhance README and documentation for Warrior_EA project
- Updated README.md with project overview, key features, directory structure, getting started guide, and modernization roadmap.
- Added AI_NETWORK.md detailing the neural network and AI/ML infrastructure, including architecture, components, usage patterns, and next steps.
- Introduced DATABASE.md for the Database module, outlining key components, design highlights, usage patterns, and future enhancements.
- Created README.md files for Enumerations, Expert, Money, Signals, Structures, System, Trailing, Variables directories, detailing their purpose, key components, and integration notes.
- Documented the Signals subsystem, emphasizing modularity, extensibility, and AI/ML readiness.
- Added comprehensive descriptions for individual signal modules in Signals/ directory.
- Established clear integration notes and recommendations for future improvements across all modules.
2026-04-20 19:28:34 -04:00

3.4 KiB

Signals Subsystem Documentation

Overview

The signals subsystem provides a modular framework for generating, filtering, and combining trading signals in the Warrior_EA expert advisor. It supports both traditional indicator-based signals and advanced AI/ML-driven signals, as well as session and news filters for robust, context-aware decision-making.

Architecture

  • Signal Classes:
    • Each indicator or logic type is encapsulated in its own class (e.g., CSignalMA, CSignalLSTM, CSignalNewsFilter, CSignalSessionFilter).
    • All signal classes derive from a common base (e.g., CExpertSignalCustom or CExpertSignalAIBase).
  • Signal Registry:
    • Signals.mqh acts as a registry, including and exposing all available signal/filter modules for use in the EA.
  • Filter Signals:
    • Session and news filters are implemented as signals, allowing flexible composition and enabling/disablement.
  • AI/ML Integration:
    • AI-based signals (e.g., LSTM) inherit from a specialized base and are designed for integration with the neural network subsystem.

Key Classes & Responsibilities

  • CSignalMA
    • Generates signals based on the Moving Average indicator.
    • Supports parameterization (period, shift, method, applied price) and multiple pattern weights.
  • CSignalLSTM
    • Generates signals using an LSTM-based AI model.
    • Supports pattern weighting and integrates with the neural network subsystem for stateful, sequence-based predictions.
  • CSignalNewsFilter
    • Filters signals based on economic news events and impact levels.
    • Configurable lookback window and impact threshold.
  • CSignalSessionFilter
    • Filters signals based on trading session (London, New York, Tokyo).
    • Configurable session enablement and time intervals.

Features

  • Modularity: Each signal/filter is a self-contained class, easily enabled/disabled or extended.
  • Extensibility: New signals (traditional or AI-based) can be added with minimal changes to the registry.
  • Configurable: All major parameters (indicator settings, session times, news impact, etc.) are exposed for runtime configuration.
  • AI/ML Ready: Designed to support both classic and neural network-based signals, with clear integration points.

Integration Points

  • Signal Generation: All trading logic (entry/exit) is driven by the combined output of enabled signals and filters.
  • AI/ML: LSTM and other AI signals can be prioritized or blended with traditional signals for hybrid strategies.
  • Session/News Filtering: Non-signal filters (session, news) are preserved and improved for robust, context-aware trading.

Design Notes

  • Separation of Concerns: Each signal/filter class has a single responsibility, improving clarity and testability.
  • Dynamic Configuration: Move toward runtime-configurable signal pipelines for maximum flexibility.
  • Backward Compatibility: Traditional signals are preserved but can be phased out in favor of AI/ML-driven logic.

Recommendations

  • Unit Testing: Add tests for each signal/filter class, especially for edge cases and parameter validation.
  • Refactor for Dynamic Pipelines: Move from hard-coded signal inclusion to a dynamic, user-configurable pipeline.
  • Documentation: Maintain this file and add inline comments for all new signals and filters.

This documentation covers the Signals subsystem. Repeat this process for all other modules to ensure full codebase coverage and maintainability.