Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 12:58:07
Ziveleos, Роберту Иерузалимски сравнивает dofile / loadfile. Мы же обсуждаем архитектуру production-системы. Это разные уровни задачи.
* loadfile действительно мощный инструмент когда, допустим нужно перезагрузить стратегию без перезапуска всего скрипта. * require — все таки правильно для модульной архитектуры.
OrderManager, RiskManager, StateMachine, Logger - это именно модули, а их лучше (правильно) подключать через require, так как возвращаем модуль, и тут не поспоришь.
Да и моя изначальная задача не в подключениях, а в контроле зависимостей. Но в любом случае, Вы подсветили полную картину подключений.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 12:01:21
А если такой вариант рассмотреть, создать специальный модуль или глобальную таблицу, которая будет управлять всеми зависимостями. Этот подход также может решить проблему избыточной передачи зависимостей, так как мы будем централизованно контролировать, какие библиотеки и модули подключаются?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 11:21:44
Да, загрузили надо мне внимательней разобраться и переосмыслить подход.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 11:14:44
Кажется уловил разницу. а) dofile: * каждый вызов → заново читает файл * заново выполняет код * выполняется в глобальном окружении? * нет кэширования? * нет изоляции Это процедурный стиль.
б) require: * выполняет файл один раз * кэширует результат в package.loaded * возвращает модуль * позволяет строить граф зависимостей * предотвращает двойную инициализацию То есть это полноценная модульная система. Так?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 10:58:05
1. Не понял в чем разница? 2. Да, спасибо за вариант, про собственный флаг, даже не задумывался, взял на вооружение!
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 10:09:17
А вот то что я описываю, интересует в первую очередь этот момент.
Код
[QUOTE][USER=16131]VPM[/USER] написал:
-- Инициализация модулей в правильном порядке (с учётом зависимостей)
-- 1. ExecutionLedger (зависит только от Logger, ссылка на StateMachine пока не используется)
ExecutionLedger.init({ logger = Logger, stateMachine = StateMachine })
-- 2. OrderManager (зависит от ExecutionLedger и Logger)
OrderManager.init({
ExecutionLedger = ExecutionLedger,
Logger = Logger
})
-- 3. StateMachine (зависит от OrderManager, RiskManager, SignalEngine, utils, Logger)
-- RiskManager и SignalEngine ещё не инициализированы, но init только сохраняет ссылки — это допустимо.
StateMachine.init({
utils = utils,
OrderManager = OrderManager,
RiskManager = RiskManager,
SignalEngine = SignalEngine,
Logger = Logger,
ExecutionLedger = ExecutionLedger -- <-- добавить
})
-- 4. RiskManager (зависит от StateMachine, SignalEngine, utils, Logger)
RiskManager.init({
utils = utils,
StateMachine = StateMachine,
SignalEngine = SignalEngine,
Logger = Logger,
config = {
daily_loss_limit = daily_loss_limit,
max_consecutive_losses = max_consecutive_losses,
max_position_size = max_position_size,
max_total_exposure = max_total_exposure,
broker_comiss_stock = broker_comiss_stock,
broker_comiss_fut = broker_comiss_fut,
exchange_comiss_stock = exchange_comiss_stock
}
})
-- 5. SignalEngine (зависит от utils, StateMachine, Logger и конфига)
SignalEngine.init({
utils = utils,
StateMachine = StateMachine,
Logger = Logger,
config = {
broker_comiss_stock = broker_comiss_stock,
exchange_comiss_stock = exchange_comiss_stock,
broker_comiss_fut = broker_comiss_fut,
exchange_pay = exchange_pay,
div = div, -- таблица дивидендов должна быть загружена ранее
div_before_expiry = div_before_expiry,
nalog = nalog,
rate = rate,
min_edge_abs = min_edge_abs
}
})
-- 6. Watchdog (зависит от Logger, StateMachine, OrderManager, ExecutionLedger)
Watchdog.init({
Logger = Logger,
StateMachine = StateMachine,
OrderManager = OrderManager,
ExecutionLedger = ExecutionLedger,
config = {
order_timeout = order_timeout,
execution_timeout = 10
}
})
-- 7. Recovery (если есть)
Recovery.init({
Logger = Logger,
StateMachine = StateMachine
})
Recovery.recover()[/QUOTE]
Именно здесь, ни кто не по беспокоит, ни какие колбеки не прилетят, пока зависимости в модулях не установлены. А речь идет про разделение ответственности в модулях.
Что я делаю не так?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 10:03:44
Ну хорошо, давайте по порядку. Вот вариант от TGB, Так?
Код
Сборка в главном скрипте
-- main.lua
require("core.order_engine")
require("adapter.quik_exchange")
require("adapter.callbacks")
require("strategies.simple_strategy")
function main()
-- 1. Инициализация адаптера
local exchange = QuikExchange:new("SPBFUT12345", "SPBFUT", "SiH5")
-- 2. Инициализация ядра
local engine = OrderEngine:new(exchange)
-- 3. Передаём ссылку в callbacks
set_engine(engine)
-- 4. Создаём стратегию
local strategy = Strategy:new(engine)
-- 5. Главный цикл
while true do
local price_param = getParamEx(exchange.class, exchange.sec, "LAST")
local price = tonumber(price_param.param_value)
if price then
strategy:on_price(price)
engine:process()
end
sleep(100)
end
end
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
27.02.2026 08:30:00
TGB, Ну так огромная! А именно в локализации глобальных переменных для данного проекта. Да медленнее но Гарантированно!
Цитата
Nikolay написал: Поэтому OnInit - это технический колбек, просто сигнализирующий, что код исполненный выше в body скрипта при его запуске, не привел к ошибкам.
Возможно так понятней о чем разговор, это кусочки кода
Код
dofile(path .. '\\QL.lua')
dofile(path .. "\\ContanGO\\Проект\\config.lua")
local utils = dofile(path .. "\\ContanGO\\Проект\\core\\utils.lua")
local Logger = dofile(path .. "\\ContanGO\\Проект\\core\\logger.lua")
local OrderManager = dofile(path .. "\\ContanGO\\Проект\\core\\order_manager.lua")
local StateMachine = dofile(path .. "\\ContanGO\\Проект\\core\\state_machine.lua")
local Recovery = dofile(path .. "\\ContanGO\\Проект\\core\\recovery.lua")
local SignalEngine = dofile(path .. "\\ContanGO\\Проект\\core\\signal_engine.lua") -- пока не реализован, но должен считать edge
local RiskManager = dofile(path .. "\\ContanGO\\Проект\\core\\risk_manager.lua") -- проверка лимитов
local Watchdog = dofile(path .. "\\ContanGO\\Проект\\core\\watchdog.lua")
local ExecutionLedger = dofile(path .. "\\ContanGO\\Проект\\core\\execution_ledger.lua")
И дальше:
Код
function OnInit()
-- Логирование (ваш код)
Logger.init(log_file)
Logger.log("INIT", "", "Starting robot")
-- Дополнительное логирование (опционально)
do
local log = _G.getScriptPath()..'\\arbitrage.log'
toLog(log, "Start INIT robot arbitrage")
end
-- Объявление глобальных таблиц для хранения данных по инструментам
exchange_pay = {}
div_date = {}
div_before_expiry = {}
-- Инициализация контекстов для каждой акции из списка
for stock in string.gmatch(ticker_list, "%a+") do
local fut_code = futures_map[stock] or utils.findNearestFutures("SPBFUT", stock, 5)
if fut_code then
local lot_size = utils.safeParam("SPBFUT", fut_code, "LOTSIZE") or 1
StateMachine.initContext(stock, fut_code, lot_size)
-- Комиссия биржи
exchange_pay[stock] = utils.safeParam("SPBFUT", fut_code, "EXCH_PAY") or 0
-- Дата дивидендов (нужна реализация функции getDividendDate)
div_date[stock] = getDividendDate(stock)
-- Дивиденд до экспирации?
if div_date[stock] then
local exp_date = utils.safeParam("SPBFUT", fut_code, "MAT_DATE")
div_before_expiry[stock] = exp_date and (tonumber(div_date[stock]) < tonumber(exp_date))
else
div_before_expiry[stock] = false
end
Logger.log("INIT", stock, string.format("Fut=%s lot=%d", fut_code, lot_size))
else
Logger.log("ERROR", stock, "No futures found")
end
end
-- Инициализация модулей в правильном порядке (с учётом зависимостей)
-- 1. ExecutionLedger (зависит только от Logger, ссылка на StateMachine пока не используется)
ExecutionLedger.init({ logger = Logger, stateMachine = StateMachine })
-- 2. OrderManager (зависит от ExecutionLedger и Logger)
OrderManager.init({
ExecutionLedger = ExecutionLedger,
Logger = Logger
})
-- 3. StateMachine (зависит от OrderManager, RiskManager, SignalEngine, utils, Logger)
-- RiskManager и SignalEngine ещё не инициализированы, но init только сохраняет ссылки — это допустимо.
StateMachine.init({
utils = utils,
OrderManager = OrderManager,
RiskManager = RiskManager,
SignalEngine = SignalEngine,
Logger = Logger,
ExecutionLedger = ExecutionLedger -- <-- добавить
})
-- 4. RiskManager (зависит от StateMachine, SignalEngine, utils, Logger)
RiskManager.init({
utils = utils,
StateMachine = StateMachine,
SignalEngine = SignalEngine,
Logger = Logger,
config = {
daily_loss_limit = daily_loss_limit,
max_consecutive_losses = max_consecutive_losses,
max_position_size = max_position_size,
max_total_exposure = max_total_exposure,
broker_comiss_stock = broker_comiss_stock,
broker_comiss_fut = broker_comiss_fut,
exchange_comiss_stock = exchange_comiss_stock
}
})
-- 5. SignalEngine (зависит от utils, StateMachine, Logger и конфига)
SignalEngine.init({
utils = utils,
StateMachine = StateMachine,
Logger = Logger,
config = {
broker_comiss_stock = broker_comiss_stock,
exchange_comiss_stock = exchange_comiss_stock,
broker_comiss_fut = broker_comiss_fut,
exchange_pay = exchange_pay,
div = div, -- таблица дивидендов должна быть загружена ранее
div_before_expiry = div_before_expiry,
nalog = nalog,
rate = rate,
min_edge_abs = min_edge_abs
}
})
-- 6. Watchdog (зависит от Logger, StateMachine, OrderManager, ExecutionLedger)
Watchdog.init({
Logger = Logger,
StateMachine = StateMachine,
OrderManager = OrderManager,
ExecutionLedger = ExecutionLedger,
config = {
order_timeout = order_timeout,
execution_timeout = 10
}
})
-- 7. Recovery (если есть)
Recovery.init({
Logger = Logger,
StateMachine = StateMachine
})
Recovery.recover()
Logger.log("INIT", "", "All modules initialized")
end
И что здесь не так?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
26.02.2026 20:28:52
TGB, Ну Вы опять, как школьник вызубривший урок наизусть, и ни грамма отступить от догмы, ну как тут не поверить, что перед нами отличник?
Ваши заключения абсолютно верны, и подход с использованием main для инициализации и работы в многозадачной среде действительно более эффективен в случае с QUIK, где важна производительность и отсутствие блокировок. Ну все этим пользуются, и я не исключение.
Но разве разговор про это? Ведь выше все подробно описал и даже пример минимальной структуры привел. Найдите там блокирующее body?
В кои веке, удалось найти что QUIK, что однозначно гарантирует. Ничего не произойдёт в скрипте пока OnInit не просигнализирует.
Nikolay, вот пишет "Поэтому OnInit - это технический колбек, просто сигнализирующий, что код исполненный выше в body скрипта при его запуске, не привел к ошибкам. Ничего более. Делается это один раз при запуске. Поэтому там и могут быть только сугубо технические действия именно при запуске скрипта и ничего более."
Это как фазовый гарантированный переход! Из всего выше сказанного следует добавить фразу - "OnInit имеет смысл лишь как минимальная часть настройки среды"?
Мне нужна была гарантированная инициализация зависимостей в модулях между собой для контроля, простой их тусовки и замены. Дело в том, что тяжело в SciTe удержать контроль над зависимостями, а тут еще и наглядность. Именно здесь и проявляет свой характер OnInit (здесь прозрение, что хоть что есть гарантированного в QUIK и можно ставить себе на службу).
Nikolay, Ваши замечания как всегда точны и логичны. Дело тут в том что в моем варианте зона body не рассматривалась, это просто зона локализации данных и переменных. Ну а последующие восстановления ни куда не деться будем тянуть из цикла маин, тут просто вариантов нет? Или я опять что то упускаю из вида?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
26.02.2026 11:34:19
OnInit, или просто прозрение, которым хочется поделиться. Ни так давно (по меркам вечности), на страницах этого форума зашел спор, суть которого можно выразить фразой "На фига козе баян".
Высказывались опытные разработчики скриптов, мнение разделись, одни утверждали: > "OnInit не нужен, всё можно сделать в main", другие что нужен, но зачем, так ни кто и не объяснил. Я придерживался простого мнения: кому нужен пользуемся, кому не нужен не пользуемся. Пока не встал у меня вопрос, "Как отслеживать зависимости между модулями"? Пришлось детально разбираться. И вот что получилось.
Если смотреть на архитектуру QUIK Lua строго с точки зрения production-дизайна — OnInit не просто "не лишняя", а ключевая точка композиции системы. Посмотрим системно.
1. Что реально делает QUIK.
Архитектурно терминал работает так: 1. Загрузка скрипта 2. Вызов OnInit(script_path) 3. Создание отдельного потока > main() 4. Далее event callbacks (OnOrder, OnTrade, OnQuote, ...) вызываются только если main() жив
Ключевой момент. > Все callback’и не будут вызываться, если main завершился? Следовательно, main() — это lifecycle-контроллер. А OnInit() — это фаза конфигурации до старта runtime.
2. Почему в production OnInit крайне полезен. Ошибочное мнение. > "OnInit не нужен, всё можно сделать в main"? Можно. Но это плохая архитектура. А правильная архитектурная роль OnInit — это:
2.1. Корень композиции зависимостей (Composition Root ) Именно здесь правильно: * собирать зависимости * инстанцировать модули * связывать Core - Adapter - Strategy * валидировать конфигурацию * логировать старт
Это аналог: * Spring Boot bootstrap * ASP.NET Composition Root * Dependency Injection container setup Это три фундаментальных понятия современной backend-разработки, описывающих, как приложение запускается, собирается из компонентов и управляет своими зависимостями.
2.2. Fail-fast зона не менее важная. Если что-то не так: * нет доступа к счёту * отсутствует класс инструмента * нет прав * ошибка конфигурации Лучше упасть до старта main, чем в рабочем цикле.
2.3. Разделение фаз | Фаза | Что происходит | | ---------- | -------------------------- | | OnInit | Конфигурация | | main | Runtime | | Callbacks | Event-driven обработка | Это даёт чистую архитектуру.
3. OnInit особенно удобно.
3.1. Связывание зависимостей (Wiring). function OnInit(script_path)
4. Для чего НЕ стоит использовать OnInit. Не надо: запускать торговый цикл, делать в нем бесконечные sleep, ну и конечно обрабатывать рынок. Это не среда выполнения (runtime).
5. Production-подход к структуре QUIK-скрипта. И тогда просмативается правильный структурный подходС (skeleton):
-- ====================== -- Global references -- ====================== local App = {}
-- ====================== -- OnInit -- ====================== function OnInit(script_path) App = Bootstrap(script_path) end
-- ====================== -- main runtime loop -- ====================== function main() App:run() end
-- ====================== -- Event callbacks -- ====================== function OnOrder(order) App:onOrder(order) end
function OnTrade(trade) App:onTrade(trade) end
function OnStop() App:onStop() end Следовательно, так можем, централизовать систему, упрощаем тестирование, делает архитектуру масштабируемой.
6. Архитектурное мнение (строго production класса). Если мы хотим строить, multi-instrument, risk-aware, state machine driven, persistent trading system, то OnInit обязателен как "корень композиции" (composition root). Без него система будет выглядеть процедурно и хаотично.
7. Ну и моя идея. > "В ней удобно выстраивать зависимости модулей между собой для наглядности и контроля". Оказалась, абсолютно правильный инженерный подход, уровеня промышленной архитектуры. Разработчик, который фактически мыслит в терминах, Граф зависимостей (Dependency Graph), Управление жизненным циклом (Lifecycle management), Контролируемая начальная загрузка (Controlled bootstrap)
8. Что имеем, итоговое заключение. OnInit, не обязателен технически, и обязателен архитектурно в production подходе. Он делает систему, детерминированной, контролируемой, масштабируемой, безопасной, ну конечно удобной для отслеживания зависимостей самих модулей.
свободные средства для срочного рынка на едином счете
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 17:18:42
Цитата
nikolz написал: Есть две рекомендации 1) Перезаказать данные2) Пересоздать таблицу клиентского портфеля-------но если у вас в стакане все не активно, то проблема у сбера и они это знают и решают Если Вы сделаете как я написал, то проблему решат за 2 часа.
Уж ни знаю что случилось, пере заказал данные и фондовый заработал, на долго? не знаю, но это уже чудо. VPM, Спасибо
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:58:43
Ну финам бкс, там ворочают такими счетами, что мне и не снились. Да, переводы не совсем удобны, но и нет привязки к одному банку. А Если учесть что фондирование сегодня на уровнях 1%, то нужно хорошо подумать, что лучше?
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:34:58
Попробовал "Алор" кое что есть интересное, но пока не однозначно. Классический брокер, средней руки, деньги ходят по реквизитам, кто знаком поделитесь мнением?
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:26:25
Nikolay, Да решение классное на этот момент оптимальное! Я тоже сбежал. Но у меня там приличный портфель, и "срочка" иногда нужна. НО по фондовому тоже ни чего не работает. Из приложения приходится рулить.
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:14:45
А если серьезно, возможно у кого еще было подобное? Возможно что то нужно поменять в настройках, рабочего места?
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:11:32
От общения с их тех. поддержкой "кровь стынет в жилах", дождусь не позднее 17 марта 2026
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:05:55
не * это не ругательство - это аббревиатура Единый Брокерский Счет, была пока таланты не взялись за дело. Много у кого есть но как доп. сервис. Эти же решили кардинально. В копилочку талантов.
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
25.02.2026 16:00:23
Не у меня круче! После того как, головы брокера Сбер посетил * , пропали торговые операции. Не актируется функции выставления заявок, ни из одного источника? Понятно, что накрутили что то на сервере? Обратился в тех. поддержку. А сей час самое интересное. Вот ответ: "Мы начали работать с вашим вопросом № 260225-7000-942752 от 25 февраля 2026. Вернёмся с результатом не позднее 17 марта 2026. Если сроки изменятся, сообщим. Следить за статусом заявки удобно в разделе «Мои обращения»: sberbank.com/sms/ob"
А как Вам брокер? У кого круче?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
22.02.2026 10:09:15
Нужно было просто поправить стратегию, и опять на те же "грабли!"
Разделение Ответственности.
Или взгляни на свою систему, как старший инженер, проектирующий инфраструктуру под множество стратегий, а не под одну конкретную. То есть, смещаемся на уровень инженера, который проектирует платформы, и отвечает за вопрос, как сделать правильное разделение ответственности.
Теперь задачу, можно свести к правильной архитектурной проблеме — не "как сделать ещё сложнее", а где проходят границы ответственности и кто от кого должен зависеть. Правильное разделение ответственности, сформулирую правильный вектор этого подхода.
Напрашивается, разделение по типу ответственности:
A. Технологическое ядро (универсальное) B. Адаптер к qLua (инфраструктура терминала) C. Стратегический уровень (разные стратегии)
Вопрос стоит так, как избежать "Главной архитектурной ошибки", которая почти всегда возникает - слои смешаны, то есть: * Стратегия знает про OrderManager; * Recovery знает про FSM; * FSM знает про детали брокера; * Executor знает про стратегический контекст. Это делает систему, сложно тестируемой, трудно расширяемой, опасной при добавлении еще одной или другой стратегии.
Сформулирую принципы, строго условно, выделив несколько слоев.
Layer 1 — Технологическое ядро (Core Engine). Это НЕ про торговлю.
должнен быть: * универсальным, * не знать, что такое стратегия, * не знать, что такое "акция" или "фьючерс".
Ему всё равно. Если завтра ты вставишь что то другое — ядро не меняется.
Layer 2 — qLua Adapter Layer. Это тонкий слой интеграции.
за что отвечает: * оборачивает getItem / getNumberOf * обрабатывает OnTrade * обрабатывает OnOrder * делает sendTransaction * нормализует данные
Это не стратегия. Это инфраструктурный адаптер. Ядро должно зависеть от интерфейса, а не от QUIK.
Layer 3 — Strategy Layer.
Это единственный слой, где есть: * SignalEngine; * FSM арбитража; * Логика входа/выхода; * Крайние параметры (edge); * Управление позицией
Стратегия НЕ должна, читать getItem, читать getNumberOf, знать class_code, знать brokerref. Она работает с абстракцией.
Сформулирую правильные зависимости (очень важно): * Strategy > Core; * Core > BrokerAdapter; * BrokerAdapter > qLua. И НИКОГДА наоборот.
"Стратегия не знает, что такое qLua. Core не знает, что такое конкретная стратегия".
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
19.02.2026 11:40:58
nikolz, Как у Вас с брокером Сбер все корректно работает? Мне сегодня даже торговать не дает, молчу же что портфели по разному считают. В приложении одно в QUIK другое, чему верить не понятно? В приложении добавили в структуру портфеля срочный рынок, только забыли добавить метрики этой структуры. Чудеса и только. Видимо ни кто не научил этих "горе специалистов" планировать и проводить плановые работы? Хорошо, что только по кнопкам тыкают. Не хотелось бы с такими спецами на производстве столкнуться! В общем Сбер у меня чудит, что ни день то новые чудеса!
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 12:10:48
В моей текущей реализации системы, это модуль Watchdog, задача которого обеспечить непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо". И пусть цена идет куда угодно, пока состояние ни восстановлено, так как принимать решение все равно нельзя. Собственно это и есть механизм защиты от 10 сигма.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 11:35:47
Nikolay, Рассуждения мои сводятся только к 3 коллбекам исполнения, дальше просто не заглядывал. Модель светофор не рассматривал, хотя показалась интересно нужно "покумекать". Вы правы соображения субъективны, все выкладки чисто теоретические, так как систему только собрал еще даже не запускал. В соседней ветке описал от куда ноги растут. Задача стояла быть уверенным что на какой то момент времени можно утверждать что все данные пришли. алгоритм "Рекомендация от разработчиков проста - взяли данные в колбеке и передали в main, и уже там с ней работает". То есть колбеки уже напихали нам отфильтрованную информации, работаем только с ней. Ну тут даже интуитивно видно что подход более оптимален, нежели описанный в примере от TGB. Обработку таблиц вызываем когда система само диагностировала несоответствие данных. 6 инвариантов или можно сказать 6 фазовых состояний замкнутый цикл. Все. Да же если допустить, что событие несоответствия данных частое, то система перейдет в состояние опроса таблиц.
Здесь хочу добавить что рассуждения строил от приказа стоп - лосса, но так как он в QUIK такой же лимитный, то все просто расширяю на исполнение всех лимитных ордеров?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 10:56:38
Temporal Logic of Actions (TLA+) - метод, который взят за основу, — это не академическая теория, а активно используемая инженерная практика.
TLA+ применяется, критически важных системах, для верификации алгоритмов в распределённых системах, где ошибка может стоить очень дорого. Крупнейшие технологические компании, такие как Amazon Web Services (AWS) и Microsoft, применяют TLA+ как Промышленный стандарт. TLA+ помогает смоделировать взаимодействие нескольких торговых "ботов" на общем рынке и выявить сценарии, приводящие к "flash crashes" в Торговых алгоритмах. Например, его используют для проверки протоколов консенсуса в блокчейнах (таких как Solana и Tendermint ), платёжных каналов (Lightning Network ) и баз данных (Azure Cosmos DB ).
Суть. TLA+ позволяет описать систему не как код на Lua, а как набор состояний и переходов между ними. Это абстракция, в которой мы можем "забыть" о неважных деталях реализации и сосредоточиться на критической логике.
В моей текущей реализации системы это просто аналогия, Watchdog — это непрерывный контроль в реальном времени. Он утверждает: "Прямо сейчас состояние допустимо".
TLA+ даёт принципиально иной уровень гарантий: "При любом развитии событий, даже самом невероятном, система никогда не войдёт в недопустимое состояние". Эти два подхода не исключают, а идеально дополняют друг друга, обеспечивая максимальную надёжность.
Следовательно. Мы можем построить абстрактную модель системы на TLA+. Что позволит нам формально, а не только интуитивно, убедиться в том, что наши доказательства (proof-sketch) верны, а архитектура действительно гарантирует безопасность счёта при любых мыслимых сценариях работы биржи и сети.
И это совершено иная концепция безопасности. "Ни гадать а быть уверенным"!
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 10:41:19
TGB, Не я не понимаю иногда то что Вы пытаетесь донести как истину в последней инстанции. А я бывает и ошибаюсь, читаю тех. литературу и пересматриваю подходы. Но так как Вы тему отказываетесь комментировать то смысла нет перепираться. Либо приводите убедительные доводы.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 10:17:11
TGB, За ссылку спасибо, но там столько не понятных для меня слов, что не хватает моей компетенции разобраться. За то хватает их чтоб прокомментировать Ваше сообщение выше. Глобально свое мнение не поменял.
Цитата
VPM написал: 1. Зачем повторять функциональность которую реализовали разработчики и которая отлажена, скорее всего лучше чем "призрачные" коллбеки (зависящие от кода main)
Прокомментируйте почему вдруг "призрачные" коллбеки (зависящие от кода main)? Как все реализовано разработчиками посвящен целиком этот сайт, а у меня даже мысли бы не было лезть туда куда ни надо.
написал: событийная модель может их решить элегантнее, чем простое увеличение таймаутов.
Все никак не могу понять о каких таймаутах речь и как потерянное событие решается без прямого обращения к данным. Если у вас есть датчик, то только его опрос даст данные, сам он их не пришлет - это простая железка.
Речь о двух независимых потоках, QUIK / колбек и Lua / main. 1. Колбеки прилетят быстрее факт очевидный пусть даже с маловероятным событием пропусками. 2. main мы вынуждены тормозить искусственно чтоб передавать управление ЦП. Вызывая обработку таблиц из цикла маин мы должны учитывать как минимум эту задержку? 3. Сама система может находиться в 6 состояниях (модель куб состояний, где 8 вершин - фазовые переходы, 6 граней те самые инварианты), система замкнута следовательно может находится только в этих 6 состояниях. Кода находит расхождения в данных, она восстанавливает данные путем уже опроса таблиц. Так как событие редкое то и опросы редки. Все это и позволяет мне утверждать что будет более надежно обработано большее количество инструментов за меньшее время. Есть еще конечно и сама инженерия кода, но ведь обязательно кто то создаст надежный.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
16.02.2026 09:10:26
Цитата
TGB написал: Но интересно, что вы напишите на следующее. Обрабатывая коллбеки и восстанавливая их результат, вы, по сути, повторяете (но в условиях неопределенности) работу которая выполняется в QUIK при формировании его таблиц. 1. Зачем повторять функциональность которую реализовали разработчики и которая отлажена, скорее всего лучше чем "призрачные" коллбеки (зависящие от кода main), так как это было давно (до появления QLua) и проще контролируется? 2. Полагаете, что вы квалифицированнее разработчиков? 3. Вы же вроде согласны с принципом "меньше дергаешься - реже падаешь". Вам нечем заняться и хочется поразвлечься с коллбеками?
А что тут комментировать, ЧУШЬ полная! Да и обсуждение совершенно о другом.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 16:28:09
Цитата
TGB написал: VPM Забыл добавить: где доказательство безопасности счета?
А этого Вам не достаточно, или какие то слова не понятны?
Цитата
VPM написал: архитектура с чёткими инвариантами и детерминированными компонентами позволяет предсказать поведение системы в любых ситуациях, включая сбои, и гарантировать, что она не совершит опасных действий (например, не превысит лимиты, не создаст дублирующий ордер).
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 16:25:08
TGB, Я не пытаюсь навязать событийную модель как единственно верную. Я лишь показываю, что она даёт определённые преимущества в плане гарантий и детерминизма, которые могут быть критичны для сложных систем.
Ваш подход проще и для многих задач достаточен. Выбор зависит от требований к надёжности и готовности платить за сложность.
Если есть конкретные проблемы (например, потеря OnTrade), событийная модель может их решить элегантнее, чем простое увеличение таймаутов. Но если текущая система вас устраивает — нет смысла её усложнять.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 16:09:11
Я говорю о том, что архитектура с чёткими инвариантами и детерминированными компонентами позволяет предсказать поведение системы в любых ситуациях, включая сбои, и гарантировать, что она не совершит опасных действий (например, не превысит лимиты, не создаст дублирующий ордер). Это достигается не магией, а строгим проектированием. Именно поэтому в моей архитектуре колбэки не являются единственным источником истины. Они служат лишь для оперативного обновления состояния, но всегда дополняются регулярной сверкой с таблицами (reconciliation). Если колбэк потерян, система обнаружит это при следующем опросе и скорректирует состояние.
Таким образом, событийная модель не требует надёжности колбэков — она лишь использует их для уменьшения задержки!
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 15:53:04
Nikolay, CAP-теорема говорит, что в распределённой системе мы можем выбрать только две из трёх характеристик: * Consistency, * Availability, * Partition tolerance.
Биржа — это отдельный узел, с которым у нас нет синхронной связи. Мы выбираем Availability и Partition tolerance, жертвуя строгой консистентностью в реальном времени.
На практике, допускаем, что в любой момент наше локальное состояние может немного расходиться с биржевым. Но мы вводим механизмы, которые гарантируют, что это расхождение всегда будет обнаружено и исправлено за конечное время, и что в процессе расхождения система не совершит опасных действий (например, не превысит лимиты).
Именно это дают, в моем варианте, инварианты S1‑S6 и Watchdog.
Ваш подход тоже жертвует строгой консистентностью, но у него нет формальных гарантий, что в момент расхождения не будет ошибки. Вы просто надеетесь, что 1 секунд достаточно, чтобы всё "устаканилось"?
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 15:45:49
TGB, А какие слова для Вас не понятны? Повторюсь, безопасность счёта можно доказать математически, событийная модель с инвариантами и реконсиляцией — единственный известный путь.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 15:37:13
TGB, Дело несколько в другом. Действительно, колбэки в QUIK не являются гарантированными, и любая система, работающая с реальной биржей, сталкивается с задержками, потерями и недетерминизмом. CAP-теорема здесь работает в полную силу, в распределённой системе, где биржа — это внешний, неподконтрольный нам узел.
Однако, из этого не следует, что событийно-ориентированная архитектура бессмысленна?
Напротив, она предназначена именно для того, чтобы жить в мире, где события могут теряться, приходить не в том порядке или с задержкой. Разница между вашим подходом (опрос таблиц + OnTransReply) и событийной моделью не в том, что событийная модель предполагает надёжность колбэков, а в том, как она обрабатывает неопределённость!
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 15:04:30
"Но если задача стоит построить систему, которая должна быть математически корректной, отказоустойчивой и масштабируемой, без событийной модели и формальных инвариантов не обойтись. Потому что её поведение можно доказать на реальной торговле на любых объёмах и с любыми стратегиями, а не просто протестировать!" В соседней веточке подняли на мой взгляд, очень важную тему, сколько угодно можно осуждать тему "система принятия торговых решений", но если не решена задача описанная выше, все становится просто бессмысленно. Перестраивая свою систему безопасности именно к такому выводу подошел. И хочу привести ряд подходов.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 14:52:28
TGB, Описаный Вами подход не хуже и не лучше — он просто другой. Он проще и для многих задач работает, а может даже и оптимален.
Но если задача стоит построить систему, которая должна быть математически корректной, отказоустойчивой и масштабируемой, без событийной модели и формальных инвариантов не обойтись. Потому что её поведение можно доказать на реальной торговле на любых объёмах и с любыми стратегиями, а не просто протестировать!
Могу привести еще недостатки Вашего подхода, но прислушаюсь к совету
Цитата
TGB написал: Несделанное, во-первых, не ломается, а во вторых, супер эффективно, так как не требует ресурсов.
написал: Но вы так-то тоже обрабатываете "сырые" колбэки и получаете соответствующие проблемы, которые потом закрываете "костылями".
В моих роботах единственный обрабатываемый коллбек это OnTransReply по той причине, что в нем есть информация о возможных причинах отказа в выставлении заявки. При этом я предполагаю, что он может теряться и отслеживаю в таймере выставление заявки по времени, проверяя таблицу заявок (orders соответственно stop_orders). Если заявка не появилась в соответствующей таблице в течении 120 секунд, то это ошибка в выставлении и есть ветка отработки этой ошибки. Все остальное, включая случаи необходимости получения текущих данных таблиц текущих торгов и тд. я беру из таблиц QUIK, кешируя для быстрого доступа индексы используемых таблиц. Признаком изменения состояния таблиц (исключая orders, stop_orders) является изменение длины, которую можно получать функцией getNumberOf. Признаком возможных изменений в существующих записях orders и stop_orders является изменение длины таблицы сделок. Вообще, для торговли надо знать состояние своего счета и какую то картину рынка. Все это можно получить из таблиц QUIK и я не вижу смысла возни с коллбеками.
Ну говорить про этот подход и не сказать про его ограниченность, как минимум не корректно. Для простых систем да. А если у вас несколько стратегий на разных инструментах, таблицы обновляются асинхронно. Вы не можете гарантировать, что в момент принятия решения о новой сделке все кеши консистентные, то есть согласованные. Особенно остро это проявляется при работе с лимитами риска, вам нужно точно знать суммарную позицию, а она может временно «плавать» из‑за задержек обновления разных таблиц.
Ну или просто банально OnTransReply может потеряться. Вы ждёте 120 секунд — это огромный интервал. За это время рынок может уйти далеко, а вы всё ещё не знаете, исполнилась ли заявка. В результате вы можете пропустить возможность или, наоборот, ошибочно считать, что заявка не прошла, и повторить отправку (что приведёт к дублированию)?
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
15.02.2026 11:49:16
Цитата
User12501 написал: Видимо ничего здесь не сделать, придётся учитывать вероятность такой ошибки в коде.
Ну почему ни чего? Можно попробовать, двухэтапную обработку с таймаутом, решение более надежно. Ваша текущая проверка на trans_id верна, но её просто недостаточно для гарантированной обработки всех сделок. Попробуйте, внедрение кэша с таймаутом — это стандартный паттерн для работы с асинхронными и ненадежными потоками событий?
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
14.02.2026 10:12:02
"В последнее время несколько раз наблюдал такое: приходит OnTrade, в котором trans_id=0. Я знаю, что это промежуточная версия, поэтому в мой алгоритм вписано игнорировать такие вызовы, ожидая более полных. И почти всегда они приходят. Но в среднем 1-2 раза за день случается так, что полный OnTrade с ненулевым trans_id так и не приходит. В чём может быть причина?" Ответ очевиден может.
Ситуация, которую вы описываете, связана не с багом в вашем коде, а с особенностями того, как QUIK и брокерский шлюз доставляют информацию о сделках. Подобную ошибку в событийной модели допускают даже грамотные, опытные разработчики на QUIK. Используя "умную заявку" (один trans_id=const на весь жизненный цикл инструмента, для 3 таблиц) в своих подходах, отлавливал такую же проблему.
Почему полный OnTrade может не прийти? То, что за день теряется 1-2 полных события, — это тревожный, но, к сожалению, не уникальный случай для распределенных систем.
Вот наиболее вероятные причины:
* Потеря пакетов на сетевом уровне: Система QUIK и брокерский шлюз обмениваются большим количеством данных. В условиях нестабильной сети или высокой нагрузки пакет со вторым, полным, событием мог быть просто потерян.
* Сбои в очередях событий QUIK: В самом терминале или на стороне брокерского шлюза есть очереди событий. При переполнении или внутреннем сбое часть событий может быть отброшена, не доходя до вашего скрипта.
* Особенности логики брокерского шлюза: Хотя это менее вероятно, существует возможность, что в редких случаях логика шлюза, отправляющего два события (служебное и полное), дает сбой, и второе событие не генерируется.
Наверняка список можно расширить.
Очереди и двойные очереди в луа, Пример из книги Р.Е.
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 22:21:28
Если Вы про оптимизацию, то согласен без спорно быстрее. Но иногда просто нужен тупой код прямолинейный как стрела, для пользователей типа меня, просто что его можно было прочесть, и успокоится что все выполняется как надо. Здесь ключевое выполняется как надо? А разве нет?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 21:56:16
Возможно термин не удачен "Двойная очередь", но это просто перевод из учебника по луа от автора, самого луа. Мне тоже кажется не правильно, поэтому применяю термин "Двухфакторная", более логина. Но раз закрепилась от автора "Двойная очередь", то слов из песни не выбросить.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 21:47:06
Или вот это, До обсуждались, про супер:
Цитата
Nikolay написал: Nikolay , а для чего вам знать размер очереди? Вы же не извлекаете из середины? Если организуется FIFO, то берётся первый элемент из очереди до тех пор, пока там что-то есть.
А Не смущает то что мы ее задаем и вынуждены контролировать? Постоянно так Quik Ни чего нигарантирует?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 21:21:27
Цитата
Nikolay написал: Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.
А вот это обидно! А Вы уберите sleep и по рассуждаем чья инженерия кода лучше?
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 21:14:40
Это маленькая толика, возможных ситуаций, довьёт еще свои. и будем обсуждать Ваши, подход ваш так себе.
Не приходит полная версия OnTrade
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 21:11:44
User12501, Скажите на русском читаете, если нет, то какие слова Вам не понятны
Цитата
VPM написал: Просто разбираюсь с тем же самым, и вот что удалось выяснить не который слой ошибок. Почему роботы закрываются "просто так" и как это фиксят в проп-торговле? Это класс ошибок, который случается даже с идеально спроектированными системами. И причина всегда одна: > Расхождение между биржевой реальностью и состоянием в QUIK!
Вот конкретные механизмы (примеры).
1. Главная причина: Асинхронность данных в QUIK. Здесь помним QUIK — это клиент терминал, а не биржа!
Время в QUIK ~= Время на бирже local q_time = -- локальное время QUIK local e_time = -- время биржи (если доступно) Разница может быть ~ 0.1-5 секунд, а то и более!
Что происходит: 1. Биржа. Цена прошла стоп > стоп сработал; 2. QUIK (через 0.5-2 сек). Получил тик > показал в стакане; 3. Робот. Увидел в стакане > решил "стоп сработал"; 4. Но, Стоп уже сработал на бирже, а в QUIK ещё не отобразился. Результат: робот пытается отменить уже исполненный стоп > получает ошибку! --------------------------------
2. "Призрачные" стопы в QUIK. QUIK показывает активный стоп. stop_order = getItem("stop_orders", index) if stop_order.flags == 1 then -- Считаем активным -- Но на бирже он мог уже сработать! end
Это случается при: * Лаге данных (биржа > шлюз брокера > QUIK); * Частичном исполнении (часть уже исполнилась, QUIK ещё не обновил qty); * Ошибках протокола (QUIK не получил подтверждение удаления). --------------------------------
3. Классический кейс рассинхрона. Таймлайн (реальный): [00:00.000] Цена Bid = 100 000 (на бирже) [00:00.100] Цена достигает стопа 100 000 [00:00.150] Биржа исполняет стоп [00:00.300] QUIK получает обновление стакана [00:00.350] Робот видит Bid = 100 000 > думает "стоп ещё не сработан" [00:00.400] Робот пытается изменить стоп > ошибка
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 15.06.2023
12.02.2026 11:12:13
Цитата
Йцукен написал: Кольцевой буфер - для хранения ограниченного количества элементов.
Так ведь и двойная очередь ограничена количеством элементов, для этого и храним первый и последний индекс. Лично меня всегда смущает в кольцевом буфере не явная индексации, "под ложечкой ноет" а тот ли элемент получен в расчетах. В то время как в двойной все линейно.
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
11.02.2026 17:06:33
Цитата
nikolz написал: Ура! Сбербанк нашел мои позиции. Все работает.
Вы рано радуетесь все работает не корректно в части секции срочного рынка
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
11.02.2026 11:59:09
Цитата
Nikolay написал: Это у биржи. Комиссию брокера никто не отменял. Прочитайте внимательно новые тарифы.
Спасибо действительно. Здесь видимо дело вот в чем, ломается глобальный 30 летний тренд "Carry Trede", все разом поменяли маржинальные требования. А товарные рынки перекредитованы больше всего.
У себя даже собрал рабочий “BoJ-радар” в TradingView, как систему ранних предупреждений. Цель: увидеть глобальное сжатие ликвидности за 1–10 дней до падения рынков. Все просто на грани, а ниточка на которой все весит тоненькая. Стоит BoJ пошевелить в сторону увеличения, и "медный таз" неизбежен, накроет.
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
11.02.2026 11:30:30
Цитата
Nikolay написал: После изменения комиссий у Сбера на срочном рынке - этот брокер только для Фонды. Платить в десятки раз больше за контракт - это безумие.
Я торгую лимитными ордерами а там 0 за сделку.
Но согласен, брокер не для срочного рынка. Вот и смотрю куда податься, без ответственность ARQA и смешивания всего на брокеров приводит к тому что чудят все брокеры. Вот и хотелось бы понять кто в меньшей степени. Стоит менять "Шило на мыло"?
А Стакан 50 очень удобно я им активно пользуюсь на срочном, супер!
свободные средства для срочного рынка на едином счете
Пользователь
Сообщений: Регистрация: 15.06.2023
11.02.2026 10:43:12
Начал искать куда бы сбежать от этих "талантов", так ка и другие чудеса демонстрировали без стеснений. Обратил внимание на ВТБ, не стакан а целая книга ордеров на срочном? Кто торгует поделитесь мнением?