Система принятия решений и/или Нечеткая логика(FuzzyLogic)

Потиковое On-line обучение в режиме Реального Времени (Рантайм-адаптация). Именно этот высший стандарт прямо сейчас активирован в первом эшелоне MEO OS! Рынок постоянно меняет свои свойства, происходит дрейф концепта. Матрица, обученная на истории 2024 года, сольет депозит в турбулентности 2026 года. Поэтому нет другого способа, робот обязан обучаться непрерывно прямо во время торгов.

Т е Вы запускаете свой алгоритм в реальном времени без какой либо настройки?
---------------------
Но тогда непонятно как у Вас работают срытые цепи Маркова Для них нужна статистика  т к они работают с вероятностями состояний.
---------------------------
Эти вероятности Вы сами задали?
-------------------
Можете показать в цифрах или на графиках стрелками конкретные сделки .

nikolz,  Алгоритм запущен в реальном времени на фьючерс серебра, формирует небольшую сетку. Идет стадия "Работы над ошибками".
Касаемо Вашего интереса цепей Маркова. Настройки максимально автоматизированы, контур пользователя минимален, и еще уменьшится есть идеи как.
Принцип подхода озвучен выше. Цепь Маркова предполагает, что вся история рынка не нужна — будущее зависит только от текущего состояния портфеля и микроструктуры.
Состоит из 4 этапов. В двух словах если здесь говорить только еще больше все запутать. Подход уникальный разработанный мной, и описан в постах выше с некоторыми отвлечениями на ситуации требующими дополнительных обсуждений (Не понятных мне в основном инженерия кода). Мой лог. файл и файл истории ничего Вам не скажет только запутает.
Но Вы подали хорошую инженерную идею. Нужен рапорт технического руководителя проекта, в котором и заморозь подход, зафиксировав основные положения. Но это позже .О результатах всего проекта говорить рано, завершен только первый эшелон идут уточнения и устранение ошибок в основном технологических. Теория описана идет этап практической реализации и проверки на практике идей.  Как известно Практика и Теория вещи мало совместимые.  

Как то совсем не до оценил ситуацию. В современных реалиях Московской Биржи и актуальных версиях QUIK (9.x и выше), физика стирания TRANS_ID кардинально изменилась. Начиная с масштабных технологических модернизаций шлюзов Срочного рынка (SPECTRA TWIME/ASTS), Московская Биржа перешла на принцип сквозного сохранения клиентских идентификаторов (Persistent Client Order ID).

Как устроен современный клиринг или почему старый подход "амнезии" TRANS_ID больше не угрожает системе, и как нужно адаптировать старые скрипты и писать новые. Что удалось установить:

------------------------------
А)  Живая физика современного клиринга МосБиржи:
  1. Сквозная линковка идентификаторов. Ранее терминал QUIK действительно вычищал поле TRANS_ID в таблицах заявок и сделок сразу по завершении вечернего клирингового сеанса (19:00), так как биржевое ядро SPECTRA выдавало новые системные номера распоряжений. Теперь же, благодаря глубокой модернизации QUIK API, поле TRANS_ID сохраняется на протяжении всей торговой сессии (включая перенос через клиринг). Оно намертво связывается с биржевым уникальным ключом ORDER_KEY (номер заявки) и TRADE_NUM (номер сделки).
 
  2. Где зарыто реальное изменение. Московская Биржа действительно полностью стирает промежуточные данные, но только при переходе через календарные сутки (в момент технологического перерыва и финального клиринга в 23:50–00:05), либо при принудительном разрыве и реконнекте сессии брокером. Вечерний клиринг (18:45–19:00) больше не обнуляет память линковки транзакций внутри текущего торгового дня.
 
  3. Современный цикл внутридневного клиринга. В ходе клиринга (18:45–19:00) биржа SPECTRA производит физическое закрытие (схлопывание) промежуточных сделок и перерасчет вариационной маржи, превращая текущие сделки дня в накопленную позицию (Holding) со средней ценой, скорректированной на расчетную цену клиринга (Settlement Price).
  То есть, trades (таблица сделок) за день остаются видны, но их финансовый результат переносится на баланс счета.

------------------------------
Б) Инвариантная Сверка через OrderKey-Mapping. Насколько Профессиональный подход судить вам? Раз TRANS_ID в течение торгового дня стабилен и больше не выжигается вечерним клирингом, суверенный MEO_Order_Tracker (v5.6) получает колоссальное преимущество. Просто обязан заложить в него метод двойного ключа (Double Key Mapping).
   Тогда при запуске робот выполняет три действия:
     * Действие 1: Считывает из нашего Excel CSV Файла последнюю сохраненную строчку позиции.
     * Действие 2: Проверяет нативную таблицу заявок QUIK (orders). Если TRANS_ID текущего дня совпадает с префиксом стратегии 44... (мой 32-битный TRANS_ID ВЕБ-брокер подкорректировал), робот подтягивает под контроль Ватчдога (механизма защиты от зависаний) биржевой номер заявки (ORDER_KEY).
     * Действие 3: Сопоставляет сумму лотов наших подтвержденных транзакций с общим живым holding-балансом из getFuturesHolding(), чтобы жестко вычленить ручные сделки пользователя.

------------------------------
Итог - этот скорректированный вариант моего MEO_Order_Tracker, учитывающий современную физику персистентных идентификаторов QUIK (СОВРЕМЕННЫЙ СТАНДАРТ).
Архитектура теперь современного Трэкера предоставляет две главные возможности:

 1. Скрипт опирается на долгосрочное сохранение TRANS_ID внутри сессии, что гарантирует точный подхват активных сеточных лимиток Ватчдогом.
 2. Защиту от суточного стирания. Если скрипт запускается на следующий календарный день, базовый ориентир восстанавливается из Файла (.csv), а функция getFuturesHolding мгновенно выявляет дельту человеческого вмешательства.

Осталось испытать.

Nikolay,  Да спасибо, про Одера понял последовательная обработка и работа с ключом order_num.

Но я то эту механику завел чтобы отследить сделку.  Сделка принадлежит определенной стратегии.  
trans_id приходит в таблицу сделок, сами сделки храню во внутренней книге а по двум первым цифрам trans_id  (у меня 44) однозначно фильтрую принадлежность сделки из истории (допустим на следующий день) к принадлежности данной стратегии. Тем самым добиваюсь возможность использования мути подхода использую разные стратегии в одно программе.

Если следовать логике предложенной Вами Нужны ключи хранить сделок? Раздувая допустим таблицу луа, если сделок много?