VPM (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 32 След.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Начну с конца, ответив, казалось бы на вечный философский вопрос, "Что первично? Курица или Яйцо?". Объективный ответ первичен - ЗАКОН СОХРАНЕНИЯ!
Первичен не объект, а закон сохранения! Просто посмотрим на это с другой стороны, как на два взаимно дополнительных потока единой системы. Если это принимается, тогда все становится по своим местам. Сейчас покажу по чему это понимание не просто важно, а носит фундаментальный закон.

Как появляются события? Берём два состояния S(t) -> S(t+dt) => Разность Delta S Если изменение достаточно большое, рождается Событие (Event). Например Trend UP v DOWN рождает TREND_REVERSAL.  Или Risk 0.42 v 0.91 рождает RISK_LIMIT_EXCEEDED. То есть Event становится не причиной, а именем перехода между двумя состояниями. Это гораздо ближе к теории автоматов.

С этой точки зрения, куб становится совершенно понятным. Теперь видно его место. Куб — это не пространство рынка. Куб — это дискретизация пространства состояний. То есть State -> Cube(State)  Например непрерывное состояние Momentum = 0.83, Entropy = 0.28, Liquidity = 0.71 - после квантования 101. Именно поэтому куб не первичен. Он является измерительным прибором. Как АЦП (аналогово-цифровой преобразователь).

Но если посмотреть глубже, возникает вопрос: > А существует ли вообще Event как самостоятельная сущность? На мой взгляд — нет.  В физике не существует "событий". Существует только непрерывная эволюция состояния. Событие появляется только тогда, когда наблюдатель говорит: > "Вот здесь произошло нечто существенное."
То есть Event = Delta State или точнее Event = f(Delta S) где Delta S = S(t+Delta t) - S(t)
Следовательно, Event — не первичный объект. Он производный. То есть событие рождается после построения состояния, а не до него. Event исчезает как фундаментальная сущность.

Принцип двойственного потока, то, что сформулировал про капитал: Д_0 -> Т -> Д_1 и Т_0 -> Д -> Т_1 оказалось не просто экономикой. Это универсальный закон управления. Любая система имеет два взаимосвязанных потока.
   Первый поток — информационный. Он отвечает на вопрос: > Что происходит?
   Второй поток — энергетический (ресурсный). Он отвечает: > Чем система может воздействовать?
Получаем две ортогональные подсистемы.
 * Информационная Market Flow -> Market State -> Policy
 * Ресурсная Capital Flow -> Capital State -> Allocation
Получается решение принимается не только относительно анализа рынка. Оно принимается совместно рынком и ресурсом.

Это можно выразить через декартово произведение автоматов. Теперь оно получает математический смысл. Если S_m — состояние рынка, а S_c — состояние капитала, то реальное управляющее состояние S = S_m х S_c. Но управляющее воздействие определяется не просто этим произведением. Появляется отображение A: S_m x S_c -> Intent Это и есть Allocation.

Но теперь видно, что одновременно существуют два независимых процесса.
  --Эволюция информации S_m(t) -> S_m(t+Delta t)
  --Эволюция ресурсов S_c(t) -> S_c(t+Delta t)
Runtime должен синхронизировать их. То есть Runtime: (S_m,S_c) -> (S'_m,S'_c) при сохранении всех инвариантов. Теперь становится понятным Runtime. До этого утверждалось Runtime переводит State(t) -> State(t+dt)

И вот здесь появляется самый глубокий вывод. Мне кажется, всё это время искал минимальную архитектуру управляющей системы. А пришел к минимальной архитектуре "организованной материи". Потому что независимо от природы объекта всегда существуют четыре фундаментальные сущности:
1. "Поток вещества (или ресурса)" — что может быть преобразовано.
2. "Поток информации" — что описывает происходящее.
3. "Законы сохранения (инварианты)" — что нельзя нарушить.
4. "Оператор эволюции (Runtime)" — что синхронно изменяет оба потока во времени.

У себя сделал одно изменение по сравнению с тем, что строил раньше. Раньше рассматривали "Mission" как верхнюю сущность. Теперь можно утверждать, что выше Mission существует ещё более фундаментальное понятие. Закон сохранения. Именно он является первичным.

Миссия уже выбирается "внутри допустимого множества", определённого законами сохранения.
В организме нельзя поставить миссию "жить без энергии".
В автомобиле нельзя поставить миссию "ехать без топлива".
В инвестиционной системе нельзя поставить миссию "удвоить капитал за секунду без принятия риска".
То есть миссия не может противоречить фундаментальным ограничениям системы. Это очень хорошо согласуется исходной идеей: > "«Первичен не объект, а закон сохранения.»"

В торговой системе это означает принципиальный сдвиг, перестаём строить систему вокруг стратегии.

Стратегия становится лишь одной из реализаций миссии,
 миссия ограничивается инвариантами, а
 инварианты являются конкретным выражением фундаментальных законов сохранения
   капитала,
   риска,
   ликвидности и
   согласованности состояний.
   
На мой взгляд, именно здесь заканчивается этап поиска архитектуры и начинается этап построения "формальной аксиоматики MEO".

Если сформулировать 5–10 базовых аксиом (аналогично аксиомам механики или теории автоматов), то все остальные модули — Runtime, Observer, Policy, Allocation, OMS, RiskManager, EventStore — будут выводиться из них как теоремы, а не проектироваться независимо.
Это и станет настоящим фундаментом не только всей системы, но и законом проектирования автоматических систем, отвечающих принципам живого организма. Это тот момент, где архитектура может стать значительно проще и математически красивее, а главное проектируемой сверху вниз.
Работа колбеков
 
Nikolay,  Так ведь и я про это. Есть круг задач решение которых, ну если не оптимальны то хотя бы  лучший способ использовать OnParam. Просто потому что лучше ни чего нет.
Вы подняли на само деле очень важную проблему. Возраст которой можно уже исчислять десятками лет. Я с Вами целиком согласен. Полное безобразие!

Но торгуем сегодня, и решения нужны сегодня они есть? Пусть не оптимальное.  Обсуждение очень важное, у себя даже усложняю структуру у меня вообще срез по рынку (фаза), задумался дописал модули, посчитал лаги на стратегию на принятие решения на исполнение суммарный. Усложнил изохронность, разделил на 3 контура.  Встал вопрос а какой ценой лимитный ордер заполнять? Ну точно не из ТТТ.
Работа колбеков
 
Ну прямо какие то "Страсти Мордастей" написали. Обматываю не большую таблицу, первоначально задав ее:   -- Реестр параметров
MEO_Config.REQ_PARAMS_REGISTRY = {
 
"STATUS", "TRADINGSTATUS", "TRADINGPHASE",

"BUYDEPO", "SELLDEPO",

   "BIDDEPTH", "OFFERDEPTH", "NUMBIDS", "NUMOFFERS", "NUMCONTRACTS",

   "WAPRICE", "PRICEMAX", "PRICEMIN", "VOLTODAY", "VALTODAY", "QTY",
   "LAST", "BID", "OFFER"

, "STEPPRICE"
}

Ничего страшного, все на хорошей скорости проходит если понимать с каким лагом обновляется сама таблица.
Ведь дело не в оптимальности самой функции и использовании калбэка,  А в архитектуре вашей программы и круге решаемых задач.

А зачем он нужен, я специально разделил таблицу на группы параметров. Просто посмотрите. Ну ведь понятно что для высоколиквидных инструментов метрики сделок из ТТТ не годятся, для этого есть  тиковые колбэки. А как отследить если изменились параметры "PRICEMAX", "PRICEMIN" в течении сессии?  А где взять  "BIDDEPTH", "OFFERDEPTH", "NUMBIDS", "NUMOFFERS"? Опять опрос?     А посчитайте лаги?
Работа колбеков
 
Вы абсолютно правы в своих рассуждениях, и Ваш анализ обнажает главные "болевые точки" архитектуры QUIK и его связки с Lua. Разработчики терминала создали механизм, который при определённых условиях начинает работать против стабильности всей системы. Ваше наблюдение за поведением после OnCleanUp (или при обрыве связи у ВТБ) абсолютно точно описывает проблему архитектуры QUIK. Вы в этом лучше меня разбираетесь. Я лишь хочу сказать о срытой проблеме выделение памяти (Garbage Collection). Каждый вызов getParamEx возвращает Lua-таблицу с полями param_value, param_image, param_type и result.На миллионах вызовов в секунду (при подгрузке истории) создаются миллионы временных таблиц и строк. Встроенный в QUIK сборщик мусора Lua не успевает их утилизировать. Происходит микро - зависание потока, обрабатывающего скрипт. Я не давно вывел т. обезличенных сделок, волосы дыбом, что сделали из ленты! Выведите посмотрите ради интереса. Думаю тут таже история. Можно бесконечно возмущаться, а воз и ныне там. Я о другом как быть в этой ситуации?
Разберу мой код выше. Посмотрите в примере именно на этот момент:

Код
while c.is_run do
    local cur_size = _G.Robot.ds:Size()
    if cur_size > last_known_size then
        last_known_size = cur_size
        c.BAR_CACHE_IDX = cur_size
        _G.Robot:ExecuteQuantumClosure(
            _G.Robot.ds,
            cur_size
        )
    end
    if _G.Robot.ProcessLearningQueue then 
        _G.Robot:ProcessLearningQueue()
    end

    if _G.Robot.TriggerUIRender then 
        _G.Robot:TriggerUIRender()
    end

    local current_work_time = GetMilliseconds() - TT
    c.LAST_EXECUTION_LAG = current_work_time
    local calculated_sleep = 200 - current_work_time

    if calculated_sleep <= 0 then 
        calculated_sleep = 1 
    end

    sleep(calculated_sleep)
    TT = GetMilliseconds()
end


Это не просто цикл. Это планировщик (scheduler).Что здесь уже правильно:
1. Баровый контур отделён от событий QUIK. Это главное. сейчас:
QUIK callbacks
       |
       v
 накопление состояния
       |
       v
     main()
       |
       v
ExecuteQuantumClosure()

То есть:
* OnQuote()    не запускает принятие решений;
* OnAllTrade() не запускает MDP;
* OnParam()    не вызывает расчёты S/D.
* DS                не вызывает расчёт индикаторов. И это уже правильно, у всех разные периоды тик, сеунда, минута.

2. Изохронность. задан период: sleep(200) То есть: 5 Hz scheduler А внутри: баровая фиксация; очередь обучения; рендеринг пользовательского интерфейса; пульс.
Это паттерн. Не, тик -> торговое решение -> ордер
            а, накопление событий + обработка, управляемая тактовым сигналом.

3. Выполнение квантового замыкания. Вот это фактически граница транзакции в MEO. Сейчас:
new bar
v
ExecuteQuantumClosure()
v
DSP
v
State Encoder
v
MDP
v
Decision
v
Execution
Именно здесь должен жить: НАЧАТЬ ТРАНЗАКЦИЮ; вычислить; подтвердить; совершить; хэш, а не в QUIK CALLBACK.
Ну по крайней мере сейчас так представляется.
Работа колбеков
 
В моем примере выше, архитектура устроена так что, все колбэки ни чего не делают, они "ТУПЫЕ", их задача сводится просигнализировать "Терминал сообщает, что параметры инструмента изменились". Это другой уровень абстракции.
В этой архитектуре главное: QUIK callbacks нельзя превращать в бизнес-события напрямую

Код
function OnParam(class_code, sec_code)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.ProcessParamEvent and type(Robot.ProcessParamEvent) == "function" then 
        Robot:ProcessParamEvent(class_code, sec_code) 
    end
end


У Вас же идет вызов тяжеловеса, еще нужно понять где фильтруется:
Код
function _G.OnParam(class_code,  sec_code)
    local last_price = tonumber((getParamEx(class_code,  sec_code, 'LAST') or {}).param_value) or nil

   -- if rev_lis[sec_code] then
      -- GetPrice(class_code,  sec_code)
   -- end
end
Работа колбеков
 
Просто мысли вслух. Таблицы обезличенных сделок и левел2 это тиковые данные, в то время как  OnParam приходит пакетами примерно раз в секунду. Я кто тому что и очереди и буфер  и тайм фреймы у них ме могут быть одинаковы. OnParam требует индивидуального подхода и подписок на параметры. Может собака в сомой обработке зарыта?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Фантастика, как математически точно, топология куба состояний 2^3 накладывается на экономический цикл капитала и физику комплементарного переключения, описывая канонический гамильтонов цикл (или цикл Грея) по ребрам трехмерного куба (6 переходов), который идеально соответствует 6-фазной метаморфозе капитала Маркса или полному 6-тактному циклу трехфазного мостового инвертора в электротехнике.
Препарируя вершины куба, определив их координаты и физико-экономическую суть фазового перехода, получаем.

А. Топология Куба Состояний 2^3 Каждое состояние системы описывается вектором из 3 бинарных координат:
  1. Координата X (Товарная форма — T). Есть вещественный субстрат (1) или нет (0).
  2. Координата Y (Денежная форма — Д). Есть ликвидная абстрактная ценность (1) или нет (0).
  3. Координата Z (Производительная форма / Силовой потенциал — P). Запущена ли скрытая внутренняя работа/энергия (1) или система пассивна (0).
Каждая вершина куба — это состояние триплета [X, Y, Z]. Всего их 2^3 = 8.

Разберу этот 6-шаговый цикл с предельной точностью, проследив за тем, как на каждом ребре куба меняется ровно один бит, одно физическое или экономическое состояние. Это классическое свойство кода Грея и Гамильтонова пути, система не может менять две сущности одновременно, метаморфоза всегда последовательна. Наши координаты в пространстве 2^3: [Товар (T), Деньги (Д), Производство/Потенциал (P)].

Шаг 1: [0, 1, 0] -> [1, 1, 0] — Акт инвестирования (Рыночная сделка)
* Экономический смысл (Д -> Д + T): У инвестора были чистые деньги. Он выходит на рынок и покупает средства производства (станки, сырье) и нанимает рабочих. В момент заключения контрактов деньги еще не ушли полностью (авансированы), но товарные обязательства уже на балансе.
* Электротехнический смысл: Это подача управляющего сигнала (напряжения) на затвор верхнего транзистора (N-канал). Ток в нагрузку еще не потек (пассивное состояние), но емкость затвора начинает заряжаться. Появляется "потенциал для обмена".
* Изменение бита: Первый бит (Товар) переключается из 0 в 1. Вещество/субстрат вошло в систему.

Шаг 2: [1, 1, 0] -> [1, 0, 0] — Абсорбция капитала (Склад)
* Экономический смысл (Д + T -> T): Расчеты завершены. Деньги полностью выплачены продавцам сырья и ушли из оборотного капитала предприятия. На балансе — чистый Товар (T=1), запертый на складе. Система пассивна (P=0), фабрика еще не работает, прибыли нет. Капитал временно "омертвлен" в веществе.
* Электротехнический смысл: Затвор полностью заряжен, входные "деньги" (напряжение управления) зафиксированы. Транзистор перешел в проводящее состояние, его сопротивление упало до нуля. Но так как силовой контур питания еще закрыт внешним ключом, реального движения зарядов нет. Есть только готовый "канал проводимости" (T=1).
* Изменение бита: Второй бит (Деньги) падает из 1 в 0. Ликвидность полностью исчезла, превратившись в физическую структуру.

Шаг 3: [1, 0, 0] -> [1, 0, 1] — Фаза производства (Накачка энергией)
* Экономический смысл (T -> [T + P]): Директор нажимает на кнопку — фабрика запускается. Включаются станки, рабочие начинают тратить мускульную и интеллектуальную энергию. К пассивному товару (сырью) прикладывается живой труд (P=1). Начинается нелинейный процесс создания прибавочной стоимости.
* Электротехнический смысл: Открывается главный силовой ключ (подается внешнее напряжение питания на сток/коллектор транзистора). Через уже подготовленный на Шаге 2 канал (T=1) устремляется мощный силовой ток. Кристалл транзистора переходит в режим активного насыщения. Происходит колоссальная перекачка энергии из внешнего источника питания в магнитное или электрическое поле нагрузки (например, индуктивности мотора).
* Изменение бита: Третий бит (Производство/Потенциал) переключается из 0 в 1. Система приведена в движение, идет генерация избыточной энергии.

Шаг 4: [1, 0, 1] -> [0, 0, 1] — Финализация продукта (Консервация энергии)
* Экономический смысл ([T + P] -> T'): Процесс производства завершен. Рабочие ушли домой, станки выключены. Исходное сырье уничтожено (T из 1 стало 0). Вместо него на складе лежит абсолютно новый товар (T'), обладающий более высокой стоимостью. Живой труд (P=1) прекратился как процесс, но он "вморожен", овеществлен в этом новом продукте.
* Электротехнический смысл: Внешний силовой импульс прекращается. Ток через транзистор падает. Но накопленная в нагрузке (индуктивности) энергия не может исчезнуть в никуда. Она трансформируется. Наш транзистор закрывается, а накопленная энергия переходит в форму ЭДС самоиндукции (высокого напряжения на выходе). Ток "заперт" в поле нагрузки.
* Изменение бита: Первый бит (Исходный товар) падает из 1 в 0. Старая форма вещества уничтожена ради рождения новой.

Шаг 5: [0, 0, 1] -> [0, 1, 1] — Выход на рынок (Реализация)
* Экономический смысл (T' -> [T' + Д']): Предприятие везет готовый продукт на рынок для продажи. Появляются покупатели. Товар начинает обмениваться на золото/валюту. На этом коротком отрезке у нас одновременно есть и остатки высоколиквидного товара на складе, и приток новой, возросшей денежной массы (Д'=1). Система все еще находится под давлением рыночного цикла (P=1).
* Электротехнический смысл: Открывается нижнее (комплементарное) плечо схемы — P-канальный транзистор. Накопленная на Шаге 4 энергия самоиндукции через этот открывшийся шлюз устремляется обратно в систему (или в цепь рекуперации). Энергия поля снова превращается в мощный электрический ток обратной полярности.
* Изменение бита: Второй бит (Деньги) возвращается из 0 в 1. Система снова обретает ликвидность и денежную форму, но уже на более высоком энергетическом уровне.

Шаг 6: [0, 1, 1] -> [0, 1, 0] — Сброс прибыли и возврат в интервал
* Экономический смысл ([T' + Д'] -> Д_{старт}): Товар полностью распродан (T'=0). Капиталист фиксирует прибыль (Д'). Чтобы запустить новый цикл, он забирает чистый избыток (прибавочную стоимость \Delta Д) себе на личное потребление (или выводит в резервный фонд). В оборотном капитале предприятия остается ровно та сумма первоначальных "чистых денег", которая необходима для повторения цикла. Завод засыпает (P=0) до следующего утра. Мы вернулись в точку [0, 1, 0].
* Электротехнический смысл: Энергия, запасенная в нагрузке, полностью отдана в цепь (потребителю). Ток упал до нуля. P-канальный транзистор закрывается. Схема полностью обесточена, потенциалы выровнены (P=0). На выходе — чистый ноль, система готова принять следующий управляющий импульс.
* Изменение бита: Третий бит (Производство/Потенциал) падает из 1 в 0. Энергетический всплеск утилизирован, система вернулась в состояние покоя.

------------------------------
Анализ запрещенных вершин под углом этого цикла. Теперь, когда детально видим шаги, становится кристально ясно, почему система панически избегает двух точек:
  1. [0, 0, 0] (Абсолютный ноль / Смерть системы): Чтобы попасть сюда, например, из Шага 3 [1, 0, 0], система должна мгновенно потерять Товар, не родив ни денег, ни энергии производства. Это эквивалентно физическому уничтожению завода (пожар, бомбежка) или мгновенной конфискации всех активов без компенсации.
  2. [1, 1, 1] (Синхронный коллапс / Короткое замыкание): Посмотрите, как близко система подходит к этой опасной точке. На Шаге 1 [1, 1, 0] (Товар и Деньги уже есть) достаточно случайно подать потенциал производства (P -> 1), не дождавшись закрытия предыдущих шлюзов — и мы влетаем в [1, 1, 1]. Оба плеча открыты, деньги и товар горят одновременно в огне сквозного тока.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
К дню Энергетика, посвящается электротехнике и инвестициям.

В электротехнике и электронике есть понятие комплементарные пары — это два элемента, которые имеют абсолютно идентичные электрические параметры, но противоположную полярность (тип проводимости). Главный физический смысл комплементарности — создание симметричных схем. Что в свою очередь, позволяет эффективно управлять как положительной, так и отрицательной полуволной сигнала.

Мне стало интересно, как комплементарные пары, используемые в инженерной практике. И почему это на прямую связано с инвестициями. Обо всем и по порядку.

1. Биполярные транзисторы, NPN и PNP. Это самый классический пример, они имеют одинаковые вольт-амперные характеристики, предельные токи и коэффициенты усиления, но противоположное направление токов и управляющих напряжений. Принцип работы,  
 NPN-транзистор открывается положительным напряжением на базе, а
 PNP — отрицательным.
 
2. Полевые транзисторы, N-канальные и P-канальные. Аналог биполярной пары, но управляемый напряжением (электрическим полем), а не током. Здесь принцип работы,
  N-канальный открывается плюсом,
  P-канальный — минусом.
На этой паре построена вся современная цифровая микроэлектроника (процессоры, память). Логический каскад этой пары: когда один транзистор открыт, комплементарный ему закрыт. Важно, схема потребляет энергию только в момент переключения. Энергетики поправят если что не так.
Зон применения огромное количество есть и силовые установки, системы управления, собственно проявленный интерес вызван другим, принципом построения логических каскадов комплементарных пар (NPN и PNP - "идеальной пары").

Мне все это на помнило экономическую теорию Карла Маркса, где формулы кругооборота TДT и ДTД (напомню, Прибавочная стоимость приводит к кризисам), чем не комплементарные пары? Решил провести полную аналогии между комплементарными парами в электротехнике и капиталом. В обеих системах мы видим циклическое движение сущностей, имеющих противоположную полярность, но идентичную "стоимостную" или "энергетическую" ценность.

Аналогия I. Формула (Товар — Деньги — Товар). В экономике этот цикл описывает простое товарное обращение (например, ремесленник продает свой стул, чтобы купить хлеб). Цель цикла - потребление, качественное изменение потребительной стоимости. Сущность меняет форму, но общая ценность остается неизменной. Электротехнический изоморфизм - Конденсаторный фильтр. Это аналог пассивного переноса заряда или работы симметричного каскада в линейном режиме, где форма сигнала меняется с напряжения на ток и обратно, но никакой новой энергии (прибыли) не создается.
* Товар0 - Первичный физический носитель (в электронике — физическое смещение, например, дырочная проводимость p-типа).
* переход Деньги - Всеобщий эквивалент, среда обмена. Электронный аналог — электрический потенциал (напряжение).
переход Товар1 (заряд) конвертируется в общее поле давления (деньги), чтобы затем снова превратиться в движение зарядов.
Товар1 - Новый физический объект, конечная точка потребления (электронная проводимость n-типа).
Суть аналогии сводится к следующему. Трансформация формы ради полезного действия. Как деньги здесь выступают лишь мимолетным посредником для обмена стула на хлеб, так и потенциал на затворе является лишь посредником для перетекания энергии из одного плеча схемы в другое.

Аналогия II. Формула (Деньги — Товар — Деньги с приростом). Это формула капитала. Деньги запускаются в оборот не ради потребления, а ради возвращения с приращением (Delta Д = Д1 - Д0, прибавочная стоимость). Это активный, самовозрастающий процесс (Инвестирование). Здесь электротехнический изоморфизм (Двухтактный активный каскад класса B/D), то есть полная аналогия работы комплементарного выходного каскада на транзисторах NPN (Д) и PNP (T), подключенных к внешнему источнику питания.

* Первичные Деньги - Входной слаботочный управляющий сигнал. Это инвестиционный капитал, который запускается в схему.
* Переход в Товар - Процесс производства. Управляющий сигнал открывает транзистор противоположной полярности. Внутри кристалла (T, товарная фабрика) происходит физическая работа, под воздействием внешнего источника питания (аналог эксплуатации рабочей силы) лавинообразно генерируются новые носители заряда.
* переход в (Деньги с приращением) - Выходной мощный сигнал. Мы получаем те же самые деньги (электрический сигнал той же формы), но их энергетическая масса (ток и мощность) колоссально возросла благодаря внешней накачке.

Прибавочная стоимость в электронике (Delta Д) - Это коэффициент усиления каскада (beta или h_{FE}). Мы вложили 1 мА тока (Д0), прогнали через транзисторную структуру (T) и получили на выходе 100 мА тока (Д1). Прирост взят из внешнего блока питания (окружающей среды / живого труда).

3. Комплементарность как Макроэкономический Баланс, в современных микросхемах построенных на парах из N-канальных и P-канальных полевых транзисторов.
 * Когда N-ключ открыт и тянет линию к "земле (0)", комплементарный P-ключ строго закрыт и изолирует "питание (+V)". Ток через схему в статике равен нулю. Энергия потребляется только в момент переключения (динамический сдвиг).
 * В экономике Маркса. Это идеальный баланс спроса и предложения в условиях равновесного рынка. Когда Денежный капитал (Д, N-канал) абсорбирует Товарную массу (T, P-канал), система находится в квазистационарном состоянии. Энергия (кризис или сверхприбыль) выделяется только в моменты тектонических переключений технологических укладов (фазовых переходов макроцикла).

------------------------------
Делаем вывод аналогии.
 В экономике, если нарушить баланс фаз T и Д, наступит кризис перепроизводства (схема захлебнется товаром, который нельзя конвертировать в деньги) или гиперинфляция (деньги потеряют связь с товарным субстратом).
 В электротехнике, если нарушить комплементарность пары (например, поставить мощный NPN-транзистор с высоким коэффициентом усиления и слабый PNP-транзистор с низким), наступит асимметрия полуволн сигнала (жесткие нелинейные искажения), постоянный ток потечет в нагрузку, и схема сгорит от перегрева.
 
"На фига козе баян ..."? У меня остались внутренние сомнения в правильности спроектированной логике в модулях:
1) Спроецировать эту аналогию на уравнение Беллмана в MDP, где Деньги — это Reward (награда), а Товар — State (состояние)
2) Математически точно наложить топологию компьютерного куба состояний 2^3 на экономический цикл капитала и физику комплементарного переключения.

И еще масса всякого интересного вскрывается, в прикладном прямом использовании природных операционных механизмов.
Работа колбеков
 
Сильное заметное наблюдаемое влияние было после перехода на  *  брокер Сбер. Пришлось бросить терминал. Интересно было бы сравнить терминал до перехода на  *  и последние навороченные версии?

Но в любом случае метрики: время выполнения, нагрузку, а сейчас добавил еще и лаг лучше держать перед глазами, кроме логирования.
Работа колбеков
 
Цитата
nikolz написал:
Относительно индикатора регрессии считаю в скользящем окне. Этот индикатор лучше чем мувинги.
Так ведь и задачи стоят передними разные. 1. Лучшее описание данных 2. Элементарное усреднение и сглаживание данных. От сюда и применение разное. Их нельзя просто сравнивать, кто лучше кто хуже. Вопрос стоит  под какую задачу сто применяется.
Работа колбеков
 
Nikolay,   Если правильно понял то проблемы уже заметны на 7 инструментах? Так? ВТБ у меня очень не охотно отдает данные по отклику сервера, экспериментировать не хочу, как брокер настойки предложил, так и оставил. Торговля не активная робот упрощённый вариант, перевел его со Сбера там практически терминал встал. На Сбере скачал новый и оставил облигационный портфель и несколько самописных индикаторов с настройками как есть боюсь руками трогать все опять развалится. Робот событийный (оставил 3 инструмента для арбитража, 2 стратегии), в таком виде все крутится с неплохо скоростью и нормальное исполнение стоит на фьючерсе на серебро. Архитектура не большие модули и ОПП колбэки. В расчеты наворочены есть  MDP, но это больше сложная математика чем вычисления. Основные задержки это конечно тоже связаны c API QUIK. Все метрики технологические наблюдаемы в живую вывожу в заголовок окна робота для контроля пульса. Окно не сложное. В таком варианте работает нормально.  Накручивать инструменты побаиваюсь все обрушить, задача стоит в начале в таком виде довести до промышленного или близкого к нему уровню. Ниже колбэки которые обрабатываю + история для нескольких индикаторов.

Код
-- ====================================================================
-- ИСПРАВЛЕНО (ИЗЛОМ 2): ЧИСТЫЙ НАЛИВ ИЗ МОДУЛЯ БЕЗ ДУБЛИРОВАНИЯ ПОЛЕЙ
-- Все флаги, заголовки и REQ_PARAMS_REGISTRY уже запечатаны в MEO_Config.lua!
-- ====================================================================
_G.MEO_Config = require("MEO_Config").init()
local c = _G.MEO_Config

-- Прописываем только динамический маркер старта
c.PLATFORM_START_TIMESTAMP = os.time() 

-- ====================================================================
-- ГЛOБAЛЬНЫE КOЛЛБЭКИ ТEРМИНAЛA QUIK API С МЬЮТЕКС-ЭКРАНИРОВАНИЕМ
-- ====================================================================
function OnAllTrade(trade)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if type(Robot.ProcessAllTradeEvent) == "function" then Robot:ProcessAllTradeEvent(trade) end
end

function OnQuote(class_code, sec_code)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.BookBridge and type(Robot.BookBridge.ProcessQuoteEvent) == "function" then 
        Robot.BookBridge:ProcessQuoteEvent(class_code, sec_code) 
    end
end

function OnParam(class_code, sec_code)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.ProcessParamEvent and type(Robot.ProcessParamEvent) == "function" then 
        Robot:ProcessParamEvent(class_code, sec_code) 
    end
end

function OnFuturesClientHolding(fut_pos)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.Ledger and type(Robot.Ledger.IncorporateExchangeHolding) == "function" then 
        Robot.Ledger:IncorporateExchangeHolding(fut_pos) 
    end
end

function OnFuturesLimitChange(fut_limit)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.ProcessFuturesLimitChangeEvent and type(Robot.ProcessFuturesLimitChangeEvent) == "function" then 
        Robot:ProcessFuturesLimitChangeEvent(fut_limit) 
    end
end

function OnTrade(trade)
    if not Robot or not c.is_run or not c.IS_WARMED_UP or Robot.Is_Inside_HotPath then return end
    if Robot.Tracker and type(Robot.Tracker.ProcessTradeEvent) == "function" then 
        Robot.Tracker:ProcessTradeEvent(trade) 
    end
end

function OnTransReply(reply)
    if not Robot or not c.is_run or not c.IS_WARMED_UP then return end
    if Robot.Tracker and type(Robot.Tracker.RegisterTransReply) == "function" then 
        Robot.Tracker:RegisterTransReply(reply) 
    end
end

function OnOrder(order)
    if not Robot or not c.is_run or not c.IS_WARMED_UP then return end
    if Robot.Tracker and type(Robot.Tracker.RegisterOrderEvent) == "function" then 
        Robot.Tracker:RegisterOrderEvent(order) 
    end
end

function OnStop()
    c.is_run = false
    if Robot and type(Robot.DestroyAndUnsubscribe) == "function" then Robot:DestroyAndUnsubscribe() end
    message("MEO OS: Core supervisor engine terminated securely. All local subscriptions cleared.", 1)
    return 1000 
end

-- ====================================================================
-- ГЛАВНАЯ ТОЧКА ВХОДА ИЗОХРОННОГО РАНТАЙМА (КОНТУР А)
-- ====================================================================
function main()

    if not c.ACCOUNT or c.ACCOUNT == "" or not c.CLIENT_CODE or c.CLIENT_CODE == "" then
        c.is_run = false
        message("MEO SUPERVISOR FATAL: Ключи счета не обнаружены в ОЗУ таблицы MEO_Config.lua!", 3)
        return
    end

    package.loaded["MEO_PreFlight_Validator"] = nil
    local PreFlightLauncher = require("MEO_PreFlight_Validator")

    -- Аппаратный Handshake поднимает, прогревает и возвращает готовый объект Robot
    _G.Robot = PreFlightLauncher.ExecuteFullHandshake(c)

    if not _G.Robot then
        message("MEO SUPERVISOR FATAL: Предполётная подготовка прервана отказом шлюзов!", 3)
        return
    end

    local last_known_size = c.BAR_CACHE_IDX
    local TT = GetMilliseconds()

    while c.is_run do
        local cur_size = _G.Robot.ds:Size()
        if cur_size > 0 then
            if cur_size > last_known_size then
                last_known_size = cur_size
                c.BAR_CACHE_IDX = cur_size
                _G.Robot:ExecuteQuantumClosure(_G.Robot.ds, cur_size)
            end
        end
        
        if _G.Robot.ProcessLearningQueue then _G.Robot:ProcessLearningQueue() end
        if _G.Robot.TriggerUIRender then _G.Robot:TriggerUIRender() end
        
        local current_work_time = GetMilliseconds() - TT
        c.LAST_EXECUTION_LAG = current_work_time
        local calculated_sleep = 200 - current_work_time
        if calculated_sleep <= 0 then calculated_sleep = 1 end
        sleep(calculated_sleep)
        TT = GetMilliseconds()
    end
end
Если бы я был архитектором QUIK, Что стоило бы изменить в QUIK по-крупному
 
TGB,  Ну просто не могу ни промолчать. Вы это серьёзно? Ну в какие это времена, "Черный ящик" кому то помог?  Не примите за навязчивость, но очень Вам советую прочесть книгу доктора технических наук И.Н. Острецова. Учёный, физик-ядерщик, доктор технических наук, профессор, специалист по ядерной физике и атомной энергетике, ликвидатор Чернобыля в своих выводах и доказательствах, приходит к выводу единого начала.
Думаю хватит Вам компетенций по достоинству ее осмыслить.
От себя лишь добавлю, у любой системы есть начало и ее конец, и ее главное звено (Идея).
Робот, торгующий опционами
 
Сергей Че,  
Цитата
Сергей Че написал:
Спасибо!
А Каму?  Если nikolz,  то он сам ничего не понимает в этом. В старорусской азбуке была буква «Херъ» (или «херь») — это название буквы «Х» в старославянской и церковнославянской азбуке. По мне так последнее что не высказывание у данного автора так с этой буквы  все начинается и не имеет ни какого продолжения. Если это для
Цитата
nikolz написал:
Алиса отвечает:
То это просто среднестатистическое мнение в лучшем случае из 10 сайтов, если не специализированный ИИ. Не упрощаете, а главное не перекладывайте ответственность. Разобраться должны Вы и ни кто другой. Удачи.
При размещении заявки на продажу ошибка "Вам запрещена работа по данному торговому счету"
 
Vitalii Savinov,
Цитата
Vitalii Savinov написал:
И получаю ошибку "Вам запрещена работа по данному торговому счету"
["CLIENT_CODE"] = "XXXXXX",
 ["ACCOUNT"] = "B00BYYYYYYYYY", Нужно проверить эти поля. Почему? Точно такую ошибку получаю при торговле из стакана руками. При обновлениях либо по другим причинам слетает счет. Проверьте также что у Вас в фильтре глобальных настроек. Возможно он делает подмену. Ну точно ошибка в этих полях. Удачи.
Состояние счета, Таблица Состояние счета
 
Vitalii Savinov,  Вы напрасно ко мне апеллируете, я не явлюсь специалистов в области API QUIK. Раньше мне помогали разобраться, теперь отдаю долг. Сужу со своей колокольни, обычно с тем что у самого стоит на повестке или знакомо (сам спотыкался и пришлось детальней разбираться). Пишу в основном о своей системе о ее взрослении.

То что Вы привели мою ссылку так это авторство документации QUIK?, ссылка именно от туда. Я не понял Ваше затруднение в чем оно? Но на в скидку  посмотрите расширение данной функции (QUIK развивается API расширяется).
1) getPortfolioInfoEx - Функция предназначена для получения значений параметров таблицы «Клиентский портфель», соответствующих идентификатору участника торгов «firmid», коду клиента «client_code» и сроку расчетов «limit_kind» со значением, заданным пользователем . Необязательные аргументы код позиции «board_tag» и валюта «currency» задают параметры расчета таблицы «Клиентский портфель», при их отсутствии используются код позиции и валюта по умолчанию для указанного участника торгов («firmid»). При этом в таблице с результатом в поле «curr_tag» заполняются параметры, для которых был выполнен расчет в формате «<Валюта> - <Код позиции>.»
Формат вызова: TABLE getPortfolioInfoEx (STRING firm_id, STRING client_code, NUMBER limit_kind, [STRING board_tag, STRING currency])
Для получения значений параметров таблицы «Клиентский портфель» для клиентов срочного рынка без единой денежной позиции необходимо указать в качестве «client_code» – торговый счет на срочном рынке, а в качестве «limit_kind» – 0.
Функция возвращает таблицу Lua с параметрами таблицы «Клиентский портфель».

2) Загляните в файл справки info там есть формулы описания данной таблицы. Ни каких сложностей написать код нет. Удачи!
Как получить дату экспирации?
 
Так просто выведите и возьмите что нужно. Попробуйте так.

Код
local CLASS_CODE, SEC_CODE = "SPBFUT", "SRU6"
local class_code, sec_code = "TQCB","RU000A10F7R7" -- Инструмент   Сбербанк ПАО 001Р-SBER56
local is_run = false

function OnStop()
    is_run = false
    return 
end
function main()
    if not SEC_CODE or SEC_CODE == "" or not CLASS_CODE or CLASS_CODE == "" then
        is_run = false
        message("FATAL: Ключи не обнаружены в ОЗУ таблицы!", 3)
        return
    end
   local tSPBFUT = getSecurityInfo( CLASS_CODE, SEC_CODE )
   for name, p in pairs(tSPBFUT) do
        message( CLASS_CODE ..'; '.. SEC_CODE .. ': ' .. tostring(name) ..' = '.. tostring(p) ..'; '.. type(p))
    end
    local tTQCB = getSecurityInfo( class_code, sec_code )
   for name, p in pairs(tTQCB) do
        message( class_code ..'; '.. sec_code .. ': '.. tostring(name) ..' = '.. tostring(p) ..'; '.. type(p))
    end
    while is_run do
        sleep(1000)
   end
end
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Заглянул на огонек, сайт https://www.mesasoftware.com/TechnicalArticles.htm и вот вам пожалуйста, с первых строк, сообщение от 2026 года. Это важное ИСПРАВЛЕНИЕ от Джона Элерса, и его действительно стоит учитывать при реализации индикаторов и применении его методов.

Вместо использования старого Dominant Cycle как отдельного признака, теперь предлагается использовать скорость изменения фазы (или её производные), как более фундаментальную характеристику. Затем при необходимости вычислять оценку периода по формуле DC ~ 360 \ Delta_phi после соответствующего сглаживания и ограничения диапазона. Эта концепция ближе к современной версии методов Элерса и лучше сочетается с вероятностным представлением состояния рынка, чем попытка напрямую оценивать период как параметр синусоидальной модели. Иными словами, если реализуете методы Элерса, сегодня нужно использовать именно это ИСПРАВЛЕНИЕ как основную реализацию Dominant Cycle. А старые версии рассматривать лишь как исторические, развитие концепции.

Суть исправления можно сформулировать так. В книге "Cybernetic Analysis for Stocks and Futures" вычисление Dominant Cycle выполняется через модель чистой синусоиды, оказалось недостаточно устойчивым на реальных рыночных данных. Элерс официально отказывается от реализации через старую функцию DominantCycle. Вместо этого он рекомендует вычислять период из скорости изменения фазового угла (phase rate of change). Именно это и реализует приведённый им код http://www.mesasoftware.com/papers/Dominant%20Cycle.pdf.

Поменялась и сама концепция. Вместо оценки "какой длины синусоида лучше описывает данные", алгоритм оценивает: > "насколько быстро вращается фазовый вектор".
 Если фазовый угол увеличивается на 20° за бар, то период 360 / 20 = 18 баров
 Если скорость вращения падает 10° то период 36 баров

То есть период получается непосредственно из фазовой динамики. Это намного устойчивее, поскольку не требует, чтобы рынок был близок к идеальной синусоиде. А в самих вычислениях применяется несколько защитных механизмов.
1. RMS-нормализация: Real = LP / RMS; Imag = ROC / QRMS - делает фазу практически независимой от амплитуды.
2. Используется производная сигнала Imag = ROC, а не классический Hilbert Quadrature. Это менее "красиво" математически, но более функционально.
3. Запрет движения фазы назад if Angle < Angle[1] then Angle = Angle[1] - Фаза должна возрастать монотонно. Иначе возникают скачки периода.
4. Ограничение периода 8 <= DC <= 50 защищает от огромных выбросов при почти нулевом dPhase.
5. Hann smoothing. Последняя строка Plot1(Hann(DC, WindowLength)) - сглаживает уже вычисленный период, а не исходный сигнал, что даёт значительно меньшую задержку по сравнению со сглаживанием входных цен. Очень важна!

Это ИСПРАВЛЕНИЕ особенно хорошо согласуется с идеей и архитектурой MEO. В MEO уже есть некоторые непроявленные, латентные признаки, связанные с фазой:
 * phase flow;
 * phase acceleration;
 * energy;
 * coherence.
Ну прям впечатление, что Джон Элерс, тоже почитывает наш сайт!   :smile:
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Обратив внимание на тот факт, что у параметров обратно пропорциональная зависимость, предположил в ввести меру. Меру этих отношений. На основе которой можно сделать настоящую "механическую" модель. Подтвердить мысль о рычагах доверия. Предложить и проверить конкретную реализацию адаптивного Kalman для MEO, где Q и R вычисляются из целевого K_target, который зависит от состояния рынка (R_sphere, Rot_Power и P_sync ...).

Само понимание Q и R как рычагов доверия, а не абсолютных констант, полностью меняет подход к настройке фильтра. Вместо того чтобы подбирать числа, мы можем вычислять их из состояния рынка — энергии, ротора и периода. Kalman становится не просто фильтром, а адаптивным регулятором инерции, который перераспределяет вес между моделью и измерением в зависимости от фазы рынка. Q и R — это не магические числа, а рычаги управления доверием. Вместо того чтобы подбирать их вручную, мы используем состояние самого рынка (энергию, завихрение, период), чтобы динамически вычислять, насколько мы доверяем модели, а насколько — новому измерению.

Это превращает Kalman из статичного фильтра в интеллектуальный регулятор инерции, который:
 В шумном флэте — сглаживает и не даёт ложных сигналов.
 В тренде — быстро реагирует на движение.
 На разворотах — мгновенно переключает доверие.
И всё это без ручной настройки — просто через естественные метрики торговой системы. Это идеально ложится в архитектуру MEO, где решение принимается на основе фазового состояния рынка.

Теперь фильтр действительно становится адаптивным физическим двигателем торговой системы. А для моей системы сторонним наблюдателем, что позволяет применить еще один подход Hidden Markov Models (HMM) и наблюдатели состояния на основе убеждений (Belief-State Observers) — это концепции, обе используются для работы со скрытыми состояниями. HMM — это пассивная модель, а Belief-State Observer — это компонент управления, который делает частичную наблюдаемость частью Марковского процесса принятия решений (MDP).
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Переход от классических индикаторов к динамике векторного поля в фазовом пространстве.
(Реализованная часть этого подхода:
ATR – скаляр, задающий масштаб поля (нормировочный множитель).
RSI – скалярная потенциальная функция (сила/перекупленность).
pDI / mDI – направленные компоненты давления (векторные составляющие).
ADX – скаляр мощности поля (модуль вектора).
Velocity – первая производная ADX (градиент мощности).
Acceleration – вторая производная (кривизна/изменение градиента).
R_sphere – энергия поля (норма вектора состояния).
Rot_Power – ротор (завихрение) поля, вычисляемое через векторное произведение состояний.)

При разборе математической интерпретации и оценке лага, получаю не очень утешительный результат.

* Лаг – это среднее отставание фильтрованного сигнала от «истинного» (мгновенного) значения, если бы мы могли измерить его без шума.
Оценка вычислительного лага. Источники задержки с учетом фильтров:
Компонент            Задержка Причина
DataStream (QUIK)        ~1-2 секунды Сетевая задержка, агрегация тиков в бары
ATR (EMA, период 14) ~6-7 баров Экспоненциальное сглаживание имеет эффективную задержку (n-1)/2
ZLEMA (DI)                ~3-4 бара Zero-Lag уменьшает задержку, но не полностью
SuperSmoother (ADX)    ~4-5 баров Задержка фильтра зависит от периода
Velocity (производная) ~1-2 бара Производная усиливает шум, но запаздывает на 1 бар
Acceleration                ~2-3 бара Ещё более шумная, но запаздывание увеличивается
R_sphere, Rot_Power     ~3-5 баров Зависят от ADX, V, A, наследуют их задержку
Обработка в Lua        < 1 мс    Практически мгновенно
Отправка ордера        ~50-100 мс Сетевая задержка до биржи
Общий лаг (от момента формирования паттерна до исполнения) составляет примерно от 5 до 15 минутных баров (если период = 1 минута).
Это ~5-15 минут. Для внутридневной торговли на часовых таймфреймах это еще приемлемо.
Основной лаг в этом проекте вносят сглаживающие фильтры (SuperSmoother, ZLEMA, EMA).

Их нужно немного уменьшить, варианты:
1) Просто сократить период (14 -> 10-8), но это увеличит чувствительность к шуму.
2) Использовать Kalman-фильтр вместо EMA/SuperSmoother – он даёт меньшую задержку.
3) Применить линейную экстраполяцию (прогноз на 1-2 бара) на основе текущих значений Velocity и Acceleration.
4) Рассчитывать адаптивный период на основе ротора: если Rot_Power высок, уменьшать период (быстрее реагировать на изменения).
Например, простой адаптивный период: local dynamic_period = math.max(8, math.min(20, math.floor(14 * (1 - Rot_Power / 100)))) Это позволит быстрее реагировать на сильные завихрения.

Мне представилось - Kalman-фильтр для замены EMA (SuperSmoother прекрасно справляется со своей задачей) в системе векторных индикаторов, это то что нужно, хорошо ложится в подход МЕО.
Kalman-фильтр даёт оптимальную оценку состояния с учётом шума измерений и динамики процесса. В отличие от EMA, он имеет меньшую задержку (~1-2 бара)  и адаптивную реакцию на изменения.
Внедрение Kalman-фильтра вместо EMA:
 а) снизит задержку с ~6-8 баров до ~2-3 баров,
 б) повысит устойчивость к шуму,
 с) даст более точную оценку производных (скорости и ускорения), что улучшит расчёт ротора и градиента.

Но с ним есть одна загвоздка, абсолютно не понятно и не удобно, работать с его параметрами Q и R, как настраивать?
Можно подобрать коэффициенты эмпирически, проще создать фильтры с фиксированными параметрами, подобранными экспериментально.
Можно обновлять параметры фильтра, сделать адаптивным, при высокой волатильности увеличивать Q (быстрее адаптироваться) и уменьшать R (больше доверять измерениям).
 * Q (шум процесса), чем больше, тем быстрее фильтр адаптируется к изменениям.
 * R (шум измерения), чем больше, тем сильнее сглаживание.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Не ту ссылку скопировал вот правильная на сообщение https://forum.quik.ru/messages/forum10/message82280/topic8506/#message82280
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  Кстати, хочу отметить, зашел Ваш подход из сообщения https://forum.quik.ru/user/13952/post/all/ Опробовал у себя, получилось несколько изохронных режима луа цикла с привязкой к задачам и нагрузки QUIK. Еще раз благодарю.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,   "Все новое, хорошо забытое старое", то что в статье упоминается две заветных буквы "ИИ" еще не означает тот факт, что они не используют методы фильтрации, сглаживания, и усреднений в своих вычислениях и кодах. Важен не тот факт сколько они показали на не статистическом периоде, в условиях когда индекс сам им стремится на встречу. А факт стабильного РОСТА капитала на продолжительном периоде (то самое мат. ожидание системы).

Ну Вы то, эти элементарные, прописные вещи должны, учитывать делая свои заявления.   :smile:

Сегодня уникальное время в обработке больших массивов данных, человек мало образованный нажимая заветную кнопочку "ИИ" получает ответ на поставленный вопрос. По чему же не пользоваться, глупо. А я лишь привел свой пример, в целях показать что к ИИ нужна еще и ГОЛОВА.

Что простая междисциплинарная АНАЛОГИЯ очень даже возможна. И это абсолютно не связано с моим, кодом, это просто метод вычислений, покажет не удовлетворительный результат - заменю. Как и математика Маркова (с которой носится тут один пользователь, не буду показывать пальцем) это просто расчеты которые хорошо легли в модель. Покажут результат Ок, не покажут заменю. Что не так?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Просто покажу, Почему нужно думать ГОЛОВОЙ, а не другим местом.   :smile:

Хочу показать, как сейчас у себя применил метод АНАЛОГИИ, провожу рефакторинг кода, дописываю метод динамической адаптации параметров фильтрации на основе текущих метрик хаоса и вихревых полей. Это далеко не локальное изобретение для QLua.
Это классический междисциплинарный подход, который в науке и промышленности называется Адаптивным цифровым сглаживанием (Adaptive Signal Processing / Variable Bandwidth Filtering).

Данный подход является безальтернативным везде, где система обязана работать в критических условиях (Mission-Critical) при постоянной и непредсказуемой смене внешней среды. Вот примеры индустрии, где этот математический паттерн является жестким стандартом.

1. Авиастроение и Космонавтика (Системы Fly-by-Wire)
В бортовых компьютерах современных истребителей и космических аппаратов датчики непрерывно измеряют угловые скорости и ускорения. Аналог моей Энтропии и Ротора которые я считаю у себя в программе. Турбулентность воздушного потока, плотность атмосферы и вибрация крыла, как это работает там, них:
* Если истребитель летит в спокойном воздухе, фильтры Т3/Кальмана (именноих я автоматизирую) переходят в режим максимальной чувствительности (аналог моего v_multiplier = 0.95), чтобы пилот имел наносекундный отклик рулей.
* Но как только самолет входит в зону жесткой турбулентности или сверхзвукового барьера, датчики начинают "шуметь". Бортовой компьютер мгновенно расширяет окно сглаживания и загрубляет коэффициенты (аналог моего снижения alpha до 0.15), чтобы случайная воздушная кочка не привела к разрушению планера из-за резкого автоколебания закрылков.

 2. Медицинское оборудование (Электрокардиографы и ИВЛ)

 3. Военная робототехника и Оптическая стабилизация. В системах наведения танковых орудий, тепловизоров и подвесов применяется точно такая же математика.
 
 4. Крупные институциональные HFT-фонды (Tier-1)
У маркет-мейкеров мирового уровня (уровня Citadel или Flow Traders) этот подход зашит в их Execution Engines (Модули исполнения приказов). Здесь аналог Энтропии и Ротора. Плотность тикового потока (Quote Feed Rate) и дисбаланс стакана (Order Book Imbalance).
* В моменты спокойного рынка их алгоритмы выставляют ордера с минимальным сглаживанием, собирая копеечный спред.
* Но в секунды выхода макроэкономических новостей, когда тиковая скорость пробивает исторические экстремумы, их Т3-каскады автоматически загрубляют чувствительность, защищая роботов от токсичной ликвидности (когда крупный агрессивный фонд одной маркет-заявкой выгребает весь стакан, уничтожая пассивных маркет-мейкеров).
 
По АНАЛОГИИ просто, перенес эту фундаментальную физику в свой QLua-монолит. Так, Марковское ядро v18.8 у меня, защищено от рыночной турбулентности законами авиационной и медицинской фильтрации.
Где, параметрами Т3-Тиллсона являются:
 а)   alpha  - Переменная alpha контролирует длину скользящего окна сглаживания.
 б)  v_multiplier - Параметр контролирует агрессивность подавления шума.

И никакой мистики, а космические корабли бороздят просторы вселенной.   :wink:
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,   А вы как "грамотный специалист" Ответе на простой профессиональный вопрос: {B] как именно собрать надежный OMS-систему, как именно в промышленной OMS-системе на базе order_num определяется принадлежность ордера и сделки к конкретной стратегии[/B]? А если trans_id исчезает?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,  Внимательно прочитал ИИ, на ~90% верно, разложил, при этом заметь те не слова про анализ подхода, одни какие - то "слюни". Читая Ваши сообщения, думал Вы сами ошибки допускаете, теперь понятно почему. Вы бы ему лучше поставили задачу сделать то же самое. Пусть покажет что может?

Комментировать машинный текст на писанный за Вас, ну верх идиотизма.   :smile:  

МАШИНА предназначена для помощи человеку, а НЕ НАОБОРТ! Точно также как торговый комплекс для торговли а не лечения затычек под названием событий модели.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Архитектурная карта разделения по модулям.

(вариант обновления, 4 самостоятельных, независимых require-модуля, каждый из которых имеет свою таблицу RAM, свои правила и свой файл хранения на диске).


                    ┌───────────────────────────────┐
                    │  MEO_OMS_Supervis  │ (Главный координатор)
                    └───────────────────────────────┘
                                                                                │
        ┌───────────────────────────┼───────────────────────────┐
       
        ▼                                                                   ▼                                                                    ▼
┌──────────────────┐        ┌────  ──────────────┐        ┌──────────────────┐
│ ФАЙЛ 1 / МОДУЛЬ:              │        │ ФАЙЛ 2 / МОДУЛЬ:               │        │ ФАЙЛ 3 / МОДУЛЬ:             │
│ MEO_Order_Stream             │        │ MEO_Pos_Stream                 │        │ MEO_Trade_Stream            │
├──────────────────┤        ├──────────────────  ┤        ├──────────────────┤
│ Жизненный цикл                 │        │ Жизненный цикл                   │        │ Статистика                          │
│ ОРДЕРА                               │        │ ПОЗИЦИИ                             │        │ Round-Turn                          │
│ Матрица 6 фаз                    │        │ Матрица 4 фаз                      │        │ Расчет метрик                     │
│ meo_orders.csv                    │        │ meo_positions.csv                 │        │ meo_pnl_book.csv               │
└──────────────────┘        └──────────────────┘        └──────────────────┘

Модуль 1: MEO_Order_Stream.lua (Поток ордеров)
--------------
Матрица состояний (6 фаз): PENDING_NEW (отправлен) ──► ACTIVE (в стакане) ──► PARTIAL (частично исполнен) ──► EXECUTED (полностью залит) ──► CANCELLED (снят оператором) ──► REJECTED (отклонен биржей).
Матрица переходов: Жестко запрещает переход из CANCELLED в EXECUTED. Защищает от ложных дублей.
Хранилище: meo_orders_snapshot_SVU6.csv.

Модуль 2: MEO_Pos_Stream.lua (Поток позиций стратегии)
-------------
Матрица состояний (4 фазы): FLAT (ноль) ──► LONG (куплено) ──► SHORT (продано) ──► LOCKED (аварийная блокировка рисков).
Матрица переходов: Переход из LONG в SHORT обязан проходить через расчет средней цены и фиксацию Round-Turn кванта.
Хранилище: meo_position_lifecycle_SVU6.csv.

Модуль 3: MEO_Trade_Stream.lua (Поток сделок и Round-Turn метрик)
-------------
Задача: Ему не важны флаги и стаканы. Он ждет, когда Модуль 2 скажет: «Позиция уменьшилась на Х лотов». Он мгновенно берет цену входа, цену выхода, переводит дельту в рубли через PriceValidator и фиксирует чистый PnL.
Хранилище: meo_trades_book_SVU6.csv (Материал для расчета Профит-Фактора и Матожидания).

Модуль 4: MEO_OMS_Supervisor.lua (Диспетчер)
Глобальный паттерн - синглтон, который принимает асинхронные события QUIK (OnOrder, OnTrade), распределяет их по трем потокам-модулям и выдает Марковскому ядру чистую, верифицированную аналитику.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Конечная задача у меня стоит, не просто отфильтровать, а создание полноценного HFT-модуля OMS (Order Management System) и Книги Позиций (Position Book).
Универсального а главное надежного. На пример как ядро проектирования распределенных систем авиационного уровня надежности (Mission-Critical Systems). Просто как аналогия - ультимативный индустриальный стандарт построения систем автоматического контроля.

Ранее пробовал применять классический, канонический Конечный Автомат (FSM — Finite State Machine). Но в HFT-среде из-за многомерности данных этот паттерн эволюционировал в концепцию Иерархический конечный автомат (HFSM — Hierarchical Finite State Machine). Где состояние верхнего уровня (Позиция) зависит от состояний нижнего уровня (Ордера).

А паттерн Event Sourcing (Хроника событий). Не просто хранит текущие состояния. Он хранит потоки событий (сделки), на основе которых память робота может математически воссоздать любую точку прошлого при аварийном рестарте.

А я лишь пытаюсь все это увязать со стратегией создавшей позицию и потоки ордеров в мульти среде стратегий для себя любимой. Некий Проектировщик Мульти-Стратегий (Multi-Strategy Framework Architect). Моя задача стоит отфильтровать по стратегиям для возможного учета собственных сделок и расчета показателей конкретной стратегии. Последнее время специально привожу английский сленг названий именно для четкого отражения подхода (Перевод часто искажает смысл, а работы интересные там).

Классический клиринг не совсем то, подход с хранением собственных сделок. По trans_id — это единственный способ удержать мульти-стратегию без раздувания RAM-таблиц, и не нужно хранить миллионы ключей. Просто применяя Двойной ДНК-Маркер, генерируете 9-значный trans_id. Его первые две цифры — это жесткий код стратегии (например, 44 — Марковский куб, 55 — будущий Арбитраж, 77 — ручной трейдер). А как еще?

Мне даже странно почему разработчики внедряя Луа, не предложили свои варианты OMS / PB,  создав тем самым базу для написания просто стратегий? Конечно их пользователь конечный - брокер.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Да спасибо, про Одера понял последовательная обработка и работа с ключом order_num.

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

Если следовать логике предложенной Вами Нужны ключи хранить сделок? Раздувая допустим таблицу луа, если сделок много?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Как то совсем не до оценил ситуацию. В современных реалиях Московской Биржи и актуальных версиях 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 мгновенно выявляет дельту человеческого вмешательства.

Осталось испытать.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
А кто то знает что происходит с брокером АЛОР? Странные сообщения весят на сайте,
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
nikolz,  Алгоритм запущен в реальном времени на фьючерс серебра, формирует небольшую сетку. Идет стадия "Работы над ошибками".
Касаемо Вашего интереса цепей Маркова. Настройки максимально автоматизированы, контур пользователя минимален, и еще уменьшится есть идеи как.
Принцип подхода озвучен выше. Цепь Маркова предполагает, что вся история рынка не нужна — будущее зависит только от текущего состояния портфеля и микроструктуры.
Состоит из 4 этапов. В двух словах если здесь говорить только еще больше все запутать. Подход уникальный разработанный мной, и описан в постах выше с некоторыми отвлечениями на ситуации требующими дополнительных обсуждений (Не понятных мне в основном инженерия кода). Мой лог. файл и файл истории ничего Вам не скажет только запутает.
Но Вы подали хорошую инженерную идею. Нужен рапорт технического руководителя проекта, в котором и заморозь подход, зафиксировав основные положения. Но это позже .О результатах всего проекта говорить рано, завершен только первый эшелон идут уточнения и устранение ошибок в основном технологических. Теория описана идет этап практической реализации и проверки на практике идей.  Как известно Практика и Теория вещи мало совместимые.  :smile:
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Потиковое On-line обучение в режиме Реального Времени (Рантайм-адаптация). Именно этот высший стандарт прямо сейчас активирован в первом эшелоне MEO OS! Рынок постоянно меняет свои свойства, происходит дрейф концепта. Матрица, обученная на истории 2024 года, сольет депозит в турбулентности 2026 года. Поэтому нет другого способа, робот обязан обучаться непрерывно прямо во время торгов.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
VPM ,
А как Вы тестируете алгоритмы? Можете показать результаты тестов?

nikolz,  я не понял Ваш вопрос, стандартно есть результат или нет. В данной дисциплине все просто Мат. ожидание системы, Профит фактор, % выигрыша (прибыльных сделок). Этих 3 оценок вполне достаточно для экспресс оценки любой стратегии.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Теперь когда, Первый эшелон MEO OS v15.0 успешно переведен в режим автономного дежурства и непрерывного накопления Марковской статистики в файл.

Можно перейти к проектированию запланированного Второго Эшелона - Спот-Деривативного Арбитражного контура. В моем случае — это торговля меж рыночной неэффективностью между физическим Серебром на товарной секции Московской биржи (инструмент SILV) и нашим расчетным фьючерсом SVU6 на срочном рынке SPECTRA.

Откровенно сказать опыта здесь абсолютно нет, но "руки чешутся". Для начала, детально разберем, как этот контур устроен у институциональных HFT-профи, что из их практики мы внедрим в архитектуру, а что обязаны до осмыслить с учетом специфики терминала QUIK.

ЧТО У ПРОФИ? или Институциональный Tier-1 стандарт.  У крупных маркет-мейкеров и арбитражных фондов (уровня Jane Street или Тройка) этот контур называется "Basis Trading Engine". Они никогда не смотрят на графики. Для них рынок — это система сообщающихся сосудов, где разница цен описывается строгой формулой стоимости удержания позиции (Cost of Carry).  Где,
       F — фьючерс,
       S — спот,
r — безрисковая процентная ставка (индикатор стоимости денег),
а T-t — количество дней до экспирации.

Главный принцип профи, торговля Чистого Базиса (Basis Spread), заключается в вычислении величины B = F - S.
В нормальных условиях этот базис находится в состоянии Контанго (фьючерс дороже спота на величину ставки r).  Арбитраж при деформации, выглядит следующим образом. Если на срочном рынке SPECTRA крупный игрок начинает агрессивно выкупать фьючерс SVU6, базис аномально расширяется. Профи мгновенно делают две противоположные наносекундные транзакции:
       1) Продают дорогой фьючерс и
2) Покупают дешевый спот.
Они фиксируют чистую безрисковую доходность, которая гарантированно упадет им в карман в день экспирации, когда цены фьючерса и спота физически схлопнутся в одну точку.
Для проведения таких операций, Профи сидят на прямых FIX/FAST протоколах непосредственно в ЦОД биржи, минуя промежуточные терминалы.

Конечно мы не можем конкурировать с ними в наносекундной скорости шлюзов, но мы можем попытаться полностью переиграть их на фрактальных интервалах за счет синергии со Смарт-Мани и нашим Марковским кубом.

Вперед за дело.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
VPM ,
Ваш робот акциями не торгует, только фьючерсы?

В дальнейшем планирую расширить, а пока только фьючерсы. Позволяют и Шорт и Лонг. Да и задача пока отработать подходы. Стратегию и Исполнителя.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Встала задача, как превратит наш логгер из простого регистратора в автоматического блок-аналитика или высшая точка в архитектуре HFT-протоколирования (стандарт Audit Trail).

Внедрение такого сквозного диагностического штампа — единственный способ, перестать гадать по сырым логам и получить мгновенный, математически неопровержимый ответ, на каком именно из барьеров конвейера споткнулся или, наоборот, пробил шлюз торговый приказ.

В моем случае, это решение - Пятиступенчатый Конвейер Допуска (Логика Аудита). Торговый сигнал рождается в виртуальном пространстве Марковских цепей и, чтобы превратиться в физическую сделку на SPECTRA МосБиржи, обязан поочередно пробить 5 изолированных шлюзов (структурно можно показать так):  

[ МАРКОВСКОЕ ЯДРО ] --> Сигнал (BUY/SELL) + Полезность (расчет max_u)
           ¦
           v
------------------------¬
¦ 1. ШЛЮЗ ПОЛЕЗНОСТИ    ¦ --> Проверка: max_u >= MIN_UTILITY_GATE
L------------------------
           ¦
           v
------------------------¬
¦ 2. ТРЕНДОВЫЙ ЗАМОК    ¦ --> Проверка: Совпадение знаков Микроскопа и Радара (старшего ТФ)
L------------------------
           ¦
           v
------------------------¬
¦ 3. ФАБРИКА КАПИТАЛА   ¦ --> Проверка: Наличие ГО под Актив + лоты под сетку (CalcBuySell)
L------------------------
           ¦
           v
------------------------¬
¦ 4. РИСК-ФИЛЬТР ПОЛЯ   ¦ --> Проверка: Спред стакана <= MAX_SPREAD и Ротор < TURBULENCE
L------------------------
           ¦
           v
------------------------¬
¦ 5. БИРЖЕВОЙ ШЛЮЗ      ¦ --> Отправка TRANS_ID. Результат: EXEC_OK (Сделка) или REJECT
L------------------------

Схема первоначальная, зашита в текущий код, скорее всего претерпит изменения, но для понимания вопроса и настойки системы вполне себе.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
Тоже использую TRANS_ID.  Когда-то давно пользовал BROKER_REF, но потом отказался.  это излишнее усложнение.---------------------------- Относительно ввода заявок рукамиРешал эту проблему так:флаг - разрешить роботу управлять заявками человека  Если его установить, то робот переустанавливает заявки человека и указывает в них TRANS_ID.иначе он их игнорирует.-----------------------------  Относительно сделок , которые были по выставленным заявкам в то время , когда терминал отключен замечу следующееЭти сделки не следует считать достижением какого-либо алгоритма, так как во время их совершения алгоритм не работал.-----------------

nikolz, вы описали золотой стандарт промышленного HFT-клиринга и риск-менеджмента (принцип Sovereign Order-Flow Isolation).То, что вы сформулировали — это критически необходимый контур разделения ответственности, отделяющий алгоритмическую торговлю от человеческого фактора и системных форс-мажоров. В десках Tier-1 без такого разделения робот вообще не допускается к торгам на SPECTRA. Благодарю!
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  Ну вот можете, когда хотите! А то я забеспокоился, уж подумал не в найм подались? Как же мы тут без Вашего огнеметного сарказма? Да Что там мы разработчики пропадут без сногсшибательных алгоритмов. Вы уж не бросайте нас.  :smile:  А проблем нет есть ситуации которые требуют своего решения. Кстати собрал робота реализующего выше описанные идеи в том числе и ключ транзакций. Выводы конечно рано делать идет работа над ошибками. Но идея стратегии заложена как описал. По шести параметрам, мой микроскоп, определяет фазу, и наиболее вероятный переход, либо подтверждает сигнал радара, либо отвергает. Все по плану. И вам удачи.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Йцукен,  На самом деле это и не важно. Я конечно не специалист, так и не нужно быть главным инженером проекта, что бы понять TRANS_ID НЕ является биржевым key и не используется как внутренний торговый ключ, если Вы про это. Но и очевидно другое, Spectra знает TRANS_ID как client request identifier, хотя бы на уровне метаданных, это просто очевидно, по другому быть не может и не важно что на столбе написано.

Дело в другом это просто наиболее простой подход, чтоб не держать маппинг на своей стороне. Проблема подхода в другом, сам параметр отдан на откуп брокеру. И каждый по своему чудит с ним. А нам нужен стандарт. Ни каких гарантий нет. То что у одного может работать у другого выдаст ошибку. А я лишь предложил присвоить код стратегии и зашивать его в TRANS_ID, для обратной идентификации уже стратегии.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
/ OnAllTrade проверил не приходит. Открыл таблицу со всеми возможными параметрами, что там на ТВОРИЛИ  :unamused: , а главное зачем дублирование? Ну дело не наше что есть с тем и работаем.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Не много "покумекаем".

Вскрываем фундаментальную прикладную проблему архитектуры шлюзов QUIK:
а) параметр BROKER_REF (комментарий) ведет себя крайне нестабильно на некоторых брокерских конфигурациях. Он часто стирается или подменяется внутренними системами учета брокера при прохождении через клиринг и / или полностью отсутствует в таблицах или в срезах позиций, что делает его непригодным для сквозного восстановления контекста стратегии. И вообще не понятно тогда зачем нужен, запутать и засорять трафик?

б) Остается использовать TRANS_ID как единственный, сквозной цифровой токен идентификации. Используя как паттерн проектирования высоконадежных HFT-систем. Числовой TRANS_ID является жестким сквозным ключом. Он гарантированно и без изменений проносится биржевым ядром Spectra через всю цепочку событий:
                                             Транзакция -> Заявка (OnOrder) -> Сделка (OnTrade).  / OnAllTrade
Но имеет ограничения по количеству знаков от 10 до 14 из разных источников, более надежной информации не нашел, проверяйте.

Архитектура Нового Числового Токена для идентификации Стратегий (TRANS_ID), заключается в присвоении каждой стратегии числового id.  Введение некоего внутреннего стандарта структуры TRANS_ID при его генерации.  

Чтобы упаковать время с точностью до микросекунд (QUIK меряет мили) и уникальный код стратегии в жесткий 12-значный лимит QUIK шлюза (до 14 знаков),
применил метод конвейерного арифметического сдвига разрядов. Выделил для нашей стратегии (SMC) жесткий глобальный числовой идентификатор:
STRATEGY_CODE = 44 (его можно менять от 10 до 99 для других стратегий).

Структура конвейерного хэширования TRANS_ID (Строго 12 знаков): TRANS_ID = Внутри часовые Микросекунды + STRATEGY_CODE + level_index
Математический разбор разрядов (Позиционный вид числа) структура:

[ 0 0 0 0 0 0 0 0 ] [ 0 0 ] [ 0 ]
------------------   ------   ----
  Микросекунды        Код      Ярус
    (8 знаков)     Стратегии  сетки
                   (0..99)    (1..9)

* Пример расчета: Время внутри часа равно 3599 секунд, 999 мс и 999 mcs.
 total_mcs = 3599999999 (9 знаков). Отрезаем старший разряд через % 100000000, получая строго 8-значное число времени: 99999999.
* Умножаем на 1000: 99999999000 (11 знаков).
* Прибавляем код стратегии 44 * 10: 99999999440.
* Прибавляем индекс линии сетки level_index = 3: -> 99999999443 (Строго 11 знаков цифр!).

Как это решает проблему идентификации при восстановлении: Когда робот перезапускается после сбоя, он считывает список своих сделок/заявок. Получив число 99999999443, система выполняет обратное арифметическое декодирование:

  1. Номер яруса сетки: 12399999443 % 10 3-й ярус сетки.
  2. Код стратегии: math.floor(12399999443 / 10) % 100 44 (SMC_MODULE).
  Робот мгновенно понимает: эта сделка на бирже принадлежит нашей стратегии и закрывает именно 3-ю линию сетки, полностью восстанавливая логику траления.

Архитектурный итог модернизации:
  1. 100% защита идентификации. Ушли от нестабильного BROKER_REF. Теперь токен STRATEGY_CODE = 44 намертво "вплавлен" внутрь структуры TRANS_ID.
  Он гарантированно вернется в систему через коллбэки OnOrder и OnTrade.
  2. Лимиты шлюза соблюдены, длина строки TRANS_ID составляет ровно 11 символов, что исключает аппаратное обрезание строк шлюзом Московской Биржи.

Надеюсь ни кого не запутал, все просто пока на уровне идеи, не пробовал но код накидал.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Я просто подумал что должен быть универсальный надежный алгоритм ИСПОЛНИТЕЛЬ, который можно "заморозить", а через 300 лет вскрыть и он отработает?

А что brokerref он в одном колбеке приходит в другом нет? Возможно в таблицах, как закон - конституция присутствует? Но после всех моих мытарств сильно сомневаюсь.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
1. QUIK не хранит информации о принадлежности сделки к стратегии? А мне требуется при восстановлении.

2. Да верно у колбеков нет определенного последовательного прихода, срабатывают как хотят, многое отдано в настойках этого регламента брокеру (спасибо разработчикам), а там свои чудеса.

Так собственно в этом и вопрос. Как исполнитель сделать надежным? Здесь главную роль играют ключи? Их передача.
Пока не получена полная информация о сделке / ордере / лимитах ВСЕ блокировать? Или есть варианты?
Ну так можно все заблокировать система повиснет?

В общем мой исполнитель творит чудеса. А как сделать надежно не понимаю?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Может так  прояснит. Из лога:
SVM6 book=-2, exchange=-1 (drift=1)
HALTING TRADING due to position drift

Причина: виртуальная позиция (book) расходится с реальной позицией на бирже (exchange).
Это происходит потому, что один из ордеров был исполнен, но система его
  либо не зафиксировали,
 либо зафиксировали дважды (из-за повторной отправки после таймаута).

Я пытаюсь учет вести по стратегиям. Торговый капитал -> Позиция/Ордера -> Результат стратегии.
По постоянно получаю расхождение с внутренней книгой учета  виртуальная позиция (book) расходится с реальной позицией на бирже (exchange).

Я виню во всем ключ. Идентификаторы?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
"Хочешь спрятать — положи на самое видное место."

Почти все фундаментальные науки начинали с объектов, а потом переходили к отношениям.
 Евклид начал с точки. Потом оказалось, что геометрию определяют отношения между точками.
 Ньютон начал с тел. Потом оказалось, что физику определяют силы взаимодействия.
 Максвелл убрал частицы. Оставил поля. То есть отношения.
 Эйнштейн вообще сказал не существует силы. Есть геометрия отношений пространства-времени.
 Квантовая механика ещё дальше. Состояние системы определяется не частицами, а отношениями амплитуд.
 Шеннон не изучал сообщения. Он изучал отношения вероятностей.
 Байес не изучал события. Он изучал отношения между гипотезой и наблюдением.
 И бухгалтерия... Вот здесь я, наверное, был больше всего удивлён. Потому что двойная запись — это вообще не про деньги.
 Это машина сохранения инварианта. Каждая запись автоматически сохраняет целостность системы.
 То есть бухгалтерия уже несколько столетий использует то, что сейчас называем оператором нормировки.

Мы настолько привыкли смотреть на цену, что перестали замечать, что цена — это последняя строка протокола, а не сама система.

И вот что, на мой взгляд, оказалось идеально спрятано. Так это единица.
Мы всю жизнь воспринимаем 1 как число. А в MEO модели это не число. Это Монада (M) целостность. Это совершенно другой объект. Тогда всё начинает выглядеть несколько иначе.
Не 1 = число, а 1 = сохранённая монада.
Не 0.5, а идеальный структурный баланс.
Не 0.618, а устойчивая асимметрия отношений.
Не Цена, а протокол наблюдения.

И тогда свои достойные места занимают теории:
 * Маркса;
 * двойной записи;
 * русской мере;
 * И-Цзину;
 * проективной геометрии;
 * Шеннону;
 * Байесу;
 * рынку;
 и конечно СМЫСЛЫ.
А мы получаем ответ, почему они одновременно могут объяснить практически все.
На первый взгляд это совершенно разные дисциплины. Но если убрать терминологию, почти везде повторяется одна и та же схема:

                             {Целое} > {Отношения} > {Преобразование} > {Инвариант}

Именно эта схема, а не конкретные символы, объединяет их.

Поэтому сформулирую то, что сейчас нашли, как первую инженерную гипотезу MEO OS.

  > Любая открытая динамическая система может быть описана как эволюция взаимодополнительных отношений при сохранении фундаментальных инвариантов.

Тогда:
* Монада задаёт целостность.
* Нормировка сохраняет целостность (аддитивно и мультипликативно).
* Мера количественно выражает структуру отношений.
* Оператор эволюции изменяет отношения.
* Наблюдение формирует протокол состояния (на рынке — сделки, стакан, цена, объём, открытый интерес).

Именно слово "протокол", теперь приобретает особый смысл. Цена — это не сущность и не причина. Это запись в протоколе взаимодействий. Аналогично тому, как бухгалтерская проводка не создаёт хозяйственную операцию, а фиксирует её в согласованной системе учёта.

Всем удачи. Ну я пошел собирать MEO-000. Аксиоматика алгебры отношений. Не "рынка". Не "трейдинга". Именно алгебры отношений. И писать под них модули.
Потому что если этот уровень окажется внутренне непротиворечивым и экспериментально подтверждаемым, то рынок действительно станет лишь первой, а не единственной областью её применения.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
TGB,  Ну Вы повторяетесь, и что отсюда следует, разве то что я физику плохо знаю. Да в такой системе мы работаем, а что это отменяет из выше перечисленного. Тот факт что  система открыта ни сколько ни от меняет факт иерархичность, фрактальность кванта записи. Или Вы отменяете взаимодействие спроса и предложения. Может и сам Капитал. Да система такая и что?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Возможно сможете что то подсказать. Я знаю что Вы используете обработку таблиц в место калбеков. Но тем не менее, возможно сможете что то подсказать. Мой экзекутор постоянно ловит маппинг, внутренняя книга учета расходится с сервером. Я пытаюсь собрать в одной системе учет сделок и ордеров по разным стратегиям. То есть каждая стратегия должна знать свою позицию на выделенный торговый капитал.
То есть нужен какой то уникальный ключ для таблицы луа. Проблемы возникают когда что то слетает и нужна проверка с квик и восстановление системы. У меня возникает вообще сомнение, что событийную модульную систему можно сделать надежной?
Возможно что порекомендуете как правильно создать ключи идентификаторы а главное как их передавать через квик?
Голову уже сломал.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Давайте по порядку.
Цитата
Nikolay написал:
Так у них подход такой же, только набор параметров другой.
У меня же инвариантные преобразования взаимодействия, а их по определению не может быть много.  Принцип взаимодополнительности отсекает не допустимые переходы. Если позиция накоплена ее будут защищать, а "след на снегу" будет отражать вектор этих устремлений. Да  статистика не которая нужна ни куда не деться, но все здесь зависит от масштаба, и торгового ТФ периода планируемого удержания позиции. Используя принципы фрактальной записи в этом подходе не нужны огромные массивы данных.
Цитата
Nikolay написал:
Т.о. задача не сказать куда, а сказать как.
Да здесь в цель, от количественного анализа к качественному со своим инвариантом и оценкой. Квант по периоду оценки вывод -> действие. За чем на с ними соревноваться, важно чтобы на нашу заявку была встречная (ликвидность так ее считаем).

Цитата
Nikolay написал:
Вы же пробуете использовать набор показателей, который "как бы" описывает состояние, но по факту показывает уже прошедшую реакцию на состояние. Т.к. рынок все же содержит некий лаг, то да, возможно поймать конец движения.
Лаг, про лаг я много раз уже формулировал свой подход, здесь лишь добавлю, что в MEO он минимален (это не индикатор с заданным периодом окна). А так как вычисляется вторая производная (ускорение), то есть и некий опережающий фактор, здесь всегда чуть - чуть впереди. Пока все еще входят по тренду, MEO сообщает о замедлении тенденции давая время на принятие решения.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Nikolay,  Не могу с Вами согласиться, здесь слово (определение) прогнозирование не на своем месте. Не отвечает поставленной задаче. Уместно определение оператор состояния, а рынок как прикладная дисциплина одно из не многих. Чтобы не путаться даже дал имя (название), "Market Evolution Operator" (MEO) - это оператор, который переводит систему из одного состояния в другое. Для решения Задачи общей оценки состояния рынка, через различные взаимодополнительные инварианты. Ответ, в какой фазе рынок и возможный переход. Тогда оператор эволюции становится естественным. Он уже не прогнозирует цену. Он вычисляет S1 -> S2, а цена здесь становится лишь следствием.

Да и мощностей вычислительных особых не нужно, а за чем? Для наглядности (для человека) вывожу квант (+++-+-), для вычислений пишу бит (111010), для анализа пока использую числовое значение бита. Мой микроскоп, это не только обработка потока данных (alltrade), но и по барный анализ (как описывал). Большинство моделей рынка описывают объекты (Цена, Объем, OI, Delta).
А MEO начинает описывать отношения. Например
 Delta относительно OI
 POC относительно Median
 Close относительно POC
 Entropy относительно Liquidity
То есть рынок — это не набор величин. Это система отношений. Главное в этом подходе у всего есть своя мера. А Инварианты есть настоящее главное звено.

Приведу два простых примера для более наглядного отражения смыслов.

1) Например возьмем бухгалтерию. Есть тысячи счетов. Но бухгалтер не думает терминами объектов (касса, банк, товар, налоги). Он думает как свести баланс Актив = Пассив.
А это уже инвариант. А какие инварианты есть у рынка? Я думаю, их не очень много.

2) Теперь вспомним Smart Money. Почему они зарабатывают? Потому что они замечают нарушение инвариантов раньше остальных. Не потому что знают будущее. А потому что видят что система стала внутренне противоречивой. Это очень близко подходу с "доведением до абсурда". мы не доказываем, что рынок обязан развернуться, а ищем внутренние противоречия, при которых текущая конфигурация становится маловероятной. Smart Money интуитивно ищут: не "куда пойдет цена", а "насколько текущая структура отличается от состояния, которое должно быть при данных потоках капитала и ликвидности". Можно так сказать Smart Money = детектор нарушения инвариантов, интерпретация, они не предсказывают цену они обнаруживают -> нарушение сохранения структуры системы?

Собственная теория MEO, начинаем сама строить математическую операционную систему рынка. И это не одно и тоже что предсказать поведение цены.
Да и кванты тут не причем, вернее так сформулировать нужно Кванты, Карл Маркс и прочее, прочее это элементы структуры. Нет "букваря" по этому предмету, собираю по крупицам идеи проверяю. Как выражается один из пользователей "Украли все до нас". Вот и побираюсь по всем теориям в посках подходящих аналогий.
Что не так?
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 32 След.
Наверх