Форум QUIK [тема: Система принятия решений и/или Нечеткая логика(FuzzyLogic)]

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

Fri, 01 May 2026 20:05:55 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Извините, не верно вставил код: ====code====

  -- Унифицированная нормализация order_num
local function normalize_order_num(order_num)
   if order_num == nil then return nil end

   -- Приводим к строке
   local s = tostring(order_num)

   -- Убираем пробелы
   s = s:match("^%s*(.-)%s*$")

   -- Убираем ведущие нули (важно для QUIK)
   s = s:gsub("^0+", "")

   -- Если стало пусто > это ноль
   if s == "" then s = "0" end

   return s
end

=============
01.05.2026 20:05:55, VPM.

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

Fri, 01 May 2026 11:51:11 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Возможное решение - устранения классической проблемы.

Добавил жёсткую нормализацию order_num во всех точках, задача устранить классическую проблему number vs string и "невидимые" несовпадения ключей.
Идея проста, единая общая функция нормализации + использование её везде (save / get / delete / compare).

[CODE][-- Унифицированная нормализация order_num
local function normalize_order_num(order_num)
if order_num == nil then return nil end

-- Приводим к строке
local s = tostring(order_num)

-- Убираем пробелы
s = s:match("^%s*(.-)%s*$")

-- Убираем ведущие нули (важно для QUIK)
s = s:gsub("^0+", "")

-- Если стало пусто > это ноль
if s == "" then s = "0" end

return s
end/CODE]

Для чего? Важный нюанс (часто упускают) QUIK на все способен, иногда даёт:
* order_num = number
* потом в OnTrade → string
* иногда с ведущими нулями
.....?

Без нормализации это гарантированный рассинхрон (что теперь исправляет функция):
(v) Нет расхождения типов ("123" vs 123)
(v) Нет проблем с "000123"
А это значит, Нет “потерянных” трейдов! Стратегии получают свои сделки > позиция синхронизирована!

Возможно что то упустил проверяйте?
01.05.2026 11:51:11, VPM.

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

Thu, 30 Apr 2026 21:47:42 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Ошибка создания заявки. [GW][332] "Нехватка средств по лимитам клиента.". Кто не получал данную ошибку от QUIK у того наверняка нет торгового скрипта.

MM (Money Manager) часто увязывают с RM (Risk Manager) не разделяя ответственность, но ведь RM отвечает только за критические состояния. В то время как MM отвечает за управление количеством. А ведь задача управления количеством напрямую связана с управлением капиталом и отвечают в сумме за рост этого капитала! В то время как RM за риск и минимальные убытки! И это ключевой момент, который часто путают в реальных системах.

Посмотрим на проблему и разложим по уровням и ответственностям, чтобы был понятен профессиональный контракт MM - CA - RM, и получен ответ на вопрос почему "текущая схема скверная"?
Для единства смыслов: "контрактный подход — это проектирование компонентов через формальные, однозначные интерфейсы (контракты), которые описывают входы, выходы, побочные эффекты, ошибки и ожидаемое поведение".

Применить профессиональный контрактный подход для MM/CA/RM - это значить снять неоднозначности и сделать систему предсказуемой и тестируемой. А главное решить задачу предотвращения гонки или повторного выставления ордеров. В такой постановке идея сводится к следующим постулатам:
* RM не "контролирует лоты" — это зона ответственности MM.
* RM — только аварийная защита, stop-loss, лимиты портфеля, стресс-сценарии.
* MM отвечает за рост капитала через количество с учётом лимитов и риск-бюджета.

Почему у меня было скверное управление?
1. Смешение зон ответственности. в старых версиях стратегии сами проверяли поток, капитал и выставляли target > EE и MM фактически дублировали функции.
2. RM и MM не разграничены. RM часто блокирует или разрешает ордер одновременно с MM > гонки и дублирование проверок.
3. Нет единого контракта. стратегии могут создавать интенты независимо от текущих лимитов CA > возникает [GW][332].

Родилась схема управления капиталом. Схема ответственности и потоков капитала в стиле профессионального контрактного подхода, с выделением TS / MM / CA / EE (Execution Engine) / RM и местом GW[332].
1. TStrategy:
* Генерирует сигнал > target.
* Не контролирует лоты и не проверяет лимиты.
2. MM:
* Получает сигнал от TS > запрашивает CA > решает allowed_qty.
* Передаёт EE: только проверенное количество.
3. CA:
* Проверяет все лимиты: инструмент, стратегия, портфель.
* Возвращает allowed_qty + reason.
4. EE:
* Получает allowed_qty от MM > выставляет ордер.
* При reject / GW[332] > повторно обращается к CA / MM с backoff.
5. RM:
* Контролирует критические состояния и аварийные лимиты.
* Может отключить стратегию или весь портфель, если превышен stress limit.

Поток: TS > (signal/target) > MM > (check CA, allowed_qty) > EE > GW > PM > EE feedback > MM/TS
^
RM мониторинг критических лимитов

* MM полностью управляет количеством, согласовывает с CA.
* RM только мониторинг и аварийные действия.
* EE выполняет FSM, orphan_trades, retry, TTL.
* TS сосредоточен на генерации сигналов, фильтров и target.

Осталось воплотить в код. Удачи!
30.04.2026 21:47:42, VPM.

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

Sat, 18 Apr 2026 11:09:16 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
VPM, Вот еще что, на вскидку этот Ваш подход можно опробовать на CODEX от OPENAI. Мне кажется, там что - то подобное делается при создании навыков. Один агент и множество навыков сильно все упрощает. Тем более пока есть вариант бесплатный, можно пробовать. Навыки можно заимствовать от других пользователей. По крайней мере сильно смахивает на Вашу модель и при этом под силу одному разработчику.
18.04.2026 11:09:16, VPM.

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

Sat, 18 Apr 2026 09:35:59 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
nikolz, То что Вы описываете сильно смахивает на работу фонда с бригадами специалистов из разных областей. Молчу уже про надежность такой распределенной системы, здесь все таки основной вопрос А ЗАЧЕМ? Для проведения экспериментов ну возможно любопытно? Но я то рассуждаю о торговых программах доступных частному трейдеру. Где основное мерило успеха рост капитала, не получение прибыли а рост капитала. И все сразу становится на сои места.
18.04.2026 09:35:59, VPM.

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

Sat, 18 Apr 2026 07:51:38 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
немного поправлю...
-----------------------
Ai агенты сами не торгуют
Это фактически советники они прогнозируют состояние рынка и дают сигналы покупать или продавать .
--------------------
Эти сигналы(события) через колбек поступают управляющему скрипту и тот принимает решение что покупать и продавать и отправляет заявки через терминал.
18.04.2026 07:51:38, nikolz.

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

Sat, 18 Apr 2026 07:44:51 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
VPM написал:
Связка QUIK (QLua) + Московская биржа (MOEX) технически подходит для реализации такой архитектуры. Но есть одно огромное НО - QLua не может быть ядром такой системы.
QLua можно использовать как транспортный шлюз (OrderExecutor), в то время как искусственный интеллект и логику выносят во внешнюю среду. И я с этим полностью согласен.
Писать нейросети и AI-агентов прямо в QUIK на Lua идея так себе. Lua в QUIK однопоточный, не имеет библиотек для работы с ИИ и быстро "захлебнется" от сложных вычислений.
Выносить вычисления во внешний контур (Python/С) не мой подход. В своем подходе HFT техники тяну по ряду причин, одна из которых быстрый тест. Вторая, низкая ликвидность на MOEX, привела к тому что рынок загнали в коридор (фондовый), плохо работают среднечастотные и долгосрочных стратегии. Смена парадигмы, от жесткого программирования правил к торговле на основе намерений (intent-based trading ) и так можно реализовать. Ведь задачу можно свести к модульности и независимости, где компоненты общаются через цели, а не прямые команды, это должно повышать адаптивность и защищать от ошибок. А математику упростить.
=============
На самом деле все не так мрачно.
Дело в том, что QLua - это не VMLua а лишь библиотека функций которые создают интерфейс между VMLua и терминалом QUIK.
Никто не мешает запускать AI агентов в отдельных потоках и самостоятельных приложениях.
Смысл запускать из в скриптах запущенных в терминале если Вы хотите использовать функции из библиотеке QLua.
Но в этом нет необходимости.
--------------------------------
Рассказываю как я делаю:
В терминале я запускаю скрипт(управляющий), который распределяет события из очереди колбеков.
Колбеки есть терминальные и есть от других скриптов и приложений.
----------------------
Управляющий скрипт не только распределяет события по скриптам но и выполняем функции обработки отправки заявок.
-------------------
В терминале можно запустить еще скрипты но они не обрабатывают события терминала.
они обрабатывают события от управляющего скрипта.
Для этого тот вызывает колбеки в них и передает им задание.
------------------
Можно запустить скрипт в main в отдельном потоке.
Т е это будет новая VMLua полностью изолированная от терминала.
Она запускается не из окна терминала а в скрипте
-------------------
Можно вообще запустить отдельные приложения даже без запуска терминала.
====================
Потоки и приложения, которые запускаются не из окна терминала не имеют связи с терминалом.
В них и располагаются Ai агенты, которые торгуют каким-либо инструментом.
Т е сколько инструментов -столько агентов.
Историю обезличенных сделок агент берет из базы данных.
Эту базу для прошедших торгов создаю путем загрузки 1 минутных свечей непосредственно с биржи
Сейчас она глубиной 15 лет. ее можно создавать и для текущего дня но за это надо платить.
Поэтому для текущего дня ее наполняет управляющий скрипт.
-----------------------------------
Таким образом , нет никаких ограничений где запускать АI агента. Можно его запустить и удаленно.
Например можно таких агентов разместить на компах других игроков на бирже.
Тогда Агенты могут сообщать друг другу свои прогнозы по сделкам инструментов по которым они работают
------------------------------
В результате получается распределенная торговая сеть. Например, 100 человек объединяются в такую сеть.
ПК каждого участника отслеживает и прогнозирует например 10 инструментов.
Но каждый из них получает еще сигналы на 990 инструментов.
Что покупать, когда и на сколько каждый решает самостоятельно но ему не надо следить 990 инструментов.
18.04.2026 07:44:51, nikolz.

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

Fri, 17 Apr 2026 20:01:10 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Связка QUIK (QLua) + Московская биржа (MOEX) технически подходит для реализации такой архитектуры. Но есть одно огромное НО - QLua не может быть ядром такой системы.
QLua можно использовать как транспортный шлюз (OrderExecutor), в то время как искусственный интеллект и логику выносят во внешнюю среду. И я с этим полностью согласен.
Писать нейросети и AI-агентов прямо в QUIK на Lua идея так себе. Lua в QUIK однопоточный, не имеет библиотек для работы с ИИ и быстро "захлебнется" от сложных вычислений.
Выносить вычисления во внешний контур (Python/С) не мой подход. В своем подходе HFT техники тяну по ряду причин, одна из которых быстрый тест. Вторая, низкая ликвидность на MOEX, привела к тому что рынок загнали в коридор (фондовый), плохо работают среднечастотные и долгосрочных стратегии. Смена парадигмы, от жесткого программирования правил к торговле на основе намерений (intent-based trading ) и так можно реализовать. Ведь задачу можно свести к модульности и независимости, где компоненты общаются через цели, а не прямые команды, это должно повышать адаптивность и защищать от ошибок. А математику упростить.
17.04.2026 20:01:10, VPM.

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

Fri, 17 Apr 2026 18:00:39 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
На современном уровне это решается созданием группы AI агентов.
Вы их уже назвали.
Осталось лишь реализовать.
17.04.2026 18:00:39, nikolz.

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

Fri, 17 Apr 2026 15:50:10 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Да чуть не забыл. IntentStore — отдельный слой, буфер намерений, интентов (очередь, приоритеты). Тот самый третий не лишний!
17.04.2026 15:50:10, VPM.

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

Fri, 17 Apr 2026 15:09:59 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
«Кручу, верчу, запутать хочу»

Мой бег по кругу нашел себе новую проблематику зацикленность под общим названием Execution (Исполнение).
Или почему третий не всегда лишний. И это не из области "сообразить на троих", это когда соревнуются две команды и нужен объективный независимы судья. В нашем случае соревнования идут между потоками QUIK / Lua, а кто судья?

Что кручу, верчу. Архитектурный слой Исполнения отвечающей принципу разделения ответственности.

У меня сейчас выглядит так:
а) strategy:
* считает alpha
* говорит: "хочу позицию X"
б) PositionManager:
* хранит истинную позицию (truth)
* хранит цель (target)
* дергает ExecutionEngine
с) ExecutionEngine
* превращает target > ордера
* управляет жизненным циклом (lifecycle)
д) OrderExecutor
* гарантирует принцип - точно один раз (exact-once)
* управляет заявками.
Это уже нормальный 4-уровневый стек выполнения. Оказалось что этого не достаточно.

Есть скрытая проблема такой архитектуры, PositionManager стал на уровень маршрутизации (routing layer), что означает > PositionManager = dispatcher. А это опасно.
Почему это проблема, PositionManager теперь: хранит truth, но также управляет поток выполнения (execution flow), а это уже смешение > состояние портфеля + оркестр выполнения. И архитектура начинает "ломаться".

# проблема №1 — двойной путь управления (control path) есть:
Path A. Strategy > PositionManager > ExecutionEngine
Path B (неявный будущий риск). Strategy > ExecutionEngine это почти гарантированный будущая ошибка.

Просмотр prop-desk стандартов дал однозначный ответ, как можно надежно выстраивать данную архитектуру. Правильная индустриальная модель (важно!) должна учитывать одну абстракцию, а именно УРОВЕНЬ НАМЕРЕНИЯ (критически недостающий элемент) текущей архитектуры.

Тогда новая правильная модель архитектуры будет содержать:

Strategy
v
PositionManager
v (creates intent)
ExecutionIntentStore
v
ExecutionEngine
v
OrderExecutor

Почему НУЖЕН ExecutionIntent чтоб не упереться в потолок! Без intent layer получаешь:
* логика выполнения размазана между модулями;
* PositionManager начинает расти;
* ExecutionEngine становится "умным монстром";
* состояния гонки между стратегиями.
Следовательно, PositionManager НЕ должен вызывать ExecutionEngine напрямую! И мой забег выходит на новый круг.
17.04.2026 15:09:59, VPM.

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

Tue, 14 Apr 2026 16:05:36 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
Не будет устраивать подключу OnOrder.
=============
Но это вряд ли потребуется, т.к. такая ситуация будет обнаружена раньше, при анализе состояния активных заявок одним оператором: (getItem("Таблица заявок", "Соответствующая таблица кэша"[trans_id]).flags & 2) ~= 0
14.04.2026 16:05:36, TGB.

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

Tue, 14 Apr 2026 15:38:28 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Йцукен написал:
Если без колбэков OnOrder и цикличного опроса активных заявок, то как, поделитесь секретом?
=============
Секрета нет. Контроль реорганизации таблиц заявок (соответствия индексов записей их полям trans_id) я выполняю циклически (других вариантов для надежного контроля возможных мутаций этих таблиц в текущем QUIK я не вижу) с периодом в 5 сек. просмотром активных заявок кэша, ссылающегося на таблицы, и там же, заодно, увижу снятые неизвестно кем заявки робота. Задержка в 5 сек. меня пока устраивает. Не будет устраивать подключу OnOrder.
14.04.2026 15:38:28, TGB.

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

Tue, 14 Apr 2026 13:04:18 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
TGB,
Если без колбэков OnOrder и цикличного опроса активных заявок, то как, поделитесь секретом?
14.04.2026 13:04:18, Йцукен.

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

Tue, 14 Apr 2026 12:34:12 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Йцукен написал:
Тогда при удалении заявки, например, пользователем, брокером или биржей робот будет считать заявку активной.
=============
Это у меня обрабатывается в:

====quote====
TGB написал:
2) реорганизация используемых таблиц по любой причине;
=============

14.04.2026 12:34:12, TGB.

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

Tue, 14 Apr 2026 09:28:05 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
коллбек OnTransReply при выполнении транзакций мной используется
=============
OnTransReply вызывается при удалении заявки из Lua-скрипта.

====quote====
TGB написал:
В любом случае обрабатывается только снимаемая заявка а не все активные заявки.
=============
Тогда при удалении заявки, например, пользователем, брокером или биржей робот будет считать заявку активной.
14.04.2026 09:28:05, Йцукен.

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

Mon, 13 Apr 2026 12:41:58 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Йцукен написал:
Во втором случае как раз надо перебирать все активные заявки, которые отслеживает скрипт. Или вы как-то по другому это делаете?
=============
1. Я как то уже писал, что коллбек OnTransReply при выполнении транзакций мной используется, т.к. только в нем есть полезная информация о причинах отказа выполнения транзакции.
2. Для снятия заявки я использую два варианта: синхронный (когда роботу нечего делать) и асинхронный.
В любом случае обрабатывается только снимаемая заявка а не все активные заявки.
13.04.2026 12:41:58, TGB.

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

Mon, 13 Apr 2026 12:07:51 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
Для просмотра изменений в заявках не надо перебирать все записи orders, stop_orders.
=============

====quote====
TGB написал:
Обрабатываются варианты:
1) удаления заявок;
=============

Знаю методы:
1) колбэк;
2) либо регулярная проверка активной заявки в цикле main через getItem.
Во втором случае как раз надо перебирать все активные заявки, которые отслеживает скрипт. Или вы как-то по другому это делаете?
13.04.2026 12:07:51, Йцукен.

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

Mon, 13 Apr 2026 11:45:53 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Йцукен написал:
Вариант удаления заявки вы не рассматриваете?
=============
Обрабатываются варианты:
1) удаления заявок;
2) реорганизация используемых таблиц по любой причине;
3) перезапуск робота с восстановлением продолжения его работы.
13.04.2026 11:45:53, TGB.

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

Sun, 12 Apr 2026 22:34:25 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
Для просмотра изменений в заявках не надо перебирать все записи orders, stop_orders.
Достаточно во вновь получаемых сделках (по изменению размера) таблицы traders выбирать trans_id (или номера ордеров) и просматривать только соответствующие заявки.
=============
Вариант удаления заявки вы не рассматриваете?
12.04.2026 22:34:25, Йцукен.

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

Sun, 12 Apr 2026 15:37:35 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Добавление к предыдущему моему комментарию.
Иллюзией является представление о том, что коллбеки выполняются параллельно с потоком main. Код скрипта, включая функции коллбеков, разделяется основным потоком QUIK и потоком main. Это значит, что когда выполняется один, то другой блокируется. Переключение потоков происходит только при вызове активным потоком сишной функции (в которой нет автоматического управления памятью Lua). Одной из сишных функций является sleep. Также сишными функциями являются стандартные функции Lua.
В основном потоке выполняется много чего, смотрите по ссылке: https://forum.quik.ru/messages/forum10/message74919/topic8563/#message74919.
При обработке коллбеков основной поток может блокироваться в моменты выполнения в потоке main lua-кода. При выполнении функций коллбеков он также перестает выполнять всю остальную свою функциональность и блокирует выполнение потока main. Поэтому разработчики QUIK рекомендуют создавать между коллбеками и потоком main очереди, а сами коллбеки делать минимальными.
В текущей архитектуре QUIK интенсивное использование коллбеков, нагружая основной поток QUIK, как описано выше, негативно влияет на его функционирование и это следует учитывать при написании скриптов.
Я написал в ветке по ссылке (пункт 2), что можно бы было изменить в QUIK, чтобы уйти от описанных проблем. Там же, в конце, выложен конкретный вариант, как это можно реализовать, на уровне конкретного работающего кода на C++.
12.04.2026 15:37:35, TGB.

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

Sun, 12 Apr 2026 14:04:38 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
1.
====quote====
Йцукен написал:
А что это даёт?
=============
Реальный временной интервал циклов обработки без этого: pause + tt (время ЦП обработки цикла).
При этом реальный интервал циклов обработки:
1) pause, если tt - 1 < pause.
2) tt + 1, если tt - 1 >= pause.
Надо ли это использовать, дело ваше.

2.
====quote====
Йцукен написал:
В цикле вы дергаете getItem, независимо от того, изменились ли параметры заявки (заявок) или нет?
=============
Для просмотра изменений в заявках не надо перебирать все записи orders, stop_orders.
Достаточно во вновь получаемых сделках (по изменению размера) таблицы traders выбирать trans_id (или номера ордеров) и просматривать только соответствующие заявки.
-----
У меня доступ к таблицам прямой, кэшируется (неизменяемое в таблицах) и затраты на обращение к ним мизерные.
12.04.2026 14:04:38, TGB.

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

Sun, 12 Apr 2026 06:46:52 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Nikolay написал:

====quote====
nikolz написал:
На самом деле все совершенно иначе.
=============
Это не все иначе, а просто другой подход. Есть колбеки - ок. Используйте. Никто не мешает. Но это не означает, что нельзя делать иначе.
Я привык делать как опрос датчика, например температуры.

А колбеки я использую если данные из Квика обрабатываются через межсетевое взаимодействие. Например тот же торговый алгоритм, написанный на GO.
Но если внутри терминала, где данные есть и доступны всегда, то колбек (именно в этой реализации что есть в Квике) не является единственным и идеальным решением.
=============
Не против использования таблиц. сам делал робота в скрипте индикатора и там использовал именно таблицы, так как это проще и в индикаторах нет колбеков.
Вы же объясняете почему Вы так делаете. Я тоже объяснил почему колбеки быстрее работают.
12.04.2026 06:46:52, nikolz.

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

Sat, 11 Apr 2026 21:04:36 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Nikolay написал:
Он и опрашивается, через запомненный индекс записи в таблице. Когда ордер найден в таблице, то повторно его иска не надо, просто получить запись в таблице с свежими данными.
=============
В цикле вы дергаете getItem, независимо от того, изменились ли параметры заявки (заявок) или нет?
11.04.2026 21:04:36, Йцукен.

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

Sat, 11 Apr 2026 19:13:46 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.
Он и опрашивается, через запомненный индекс записи в таблице. Когда ордер найден в таблице, то повторно его иска не надо, просто получить запись в таблице с свежими данными.
11.04.2026 19:13:46, Nikolay.

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

Sat, 11 Apr 2026 17:04:08 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Nikolay написал:

====quote====
Йцукен написал:
Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
=============
Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.
=============
При чём тут датчик температуры?
Если уж приводить аналогию, то, чтобы узнать изменение температуры отслеживаемого датчика, не нужно проверять изменение количества датчиков, а нужно опрашивать конкретный датчик.
11.04.2026 17:04:08, Йцукен.

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

Sat, 11 Apr 2026 13:33:43 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
Йцукен написал:
Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
=============
Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.
11.04.2026 13:33:43, Nikolay.

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

Sat, 11 Apr 2026 12:42:58 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
Можно сделать паузу адаптивной к длительности основного цикла скрипта (это учтет все, в том числе и длительность обработки очереди):
=============
А что это даёт?
11.04.2026 12:42:58, Йцукен.

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

Sat, 11 Apr 2026 12:17:08 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
TGB написал:
можно реализовать проверкой (с использованием trans_id) в таблицах order, stop_order. И эту проверку надо выполнять только, когда изменяется количество записей в них.
=============
Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
11.04.2026 12:17:08, Йцукен.

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

Sat, 11 Apr 2026 11:43:31 +0300

Система принятия решений и/или Нечеткая логика(FuzzyLogic) Нечеткая логика или Система принятия решений в трейдинге в форуме Программирование на языке Lua.

====quote====
nikolz написал:
На самом деле все совершенно иначе.
=============
Это не все иначе, а просто другой подход. Есть колбеки - ок. Используйте. Никто не мешает. Но это не означает, что нельзя делать иначе.
Я привык делать как опрос датчика, например температуры.

А колбеки я использую если данные из Квика обрабатываются через межсетевое взаимодействие. Например тот же торговый алгоритм, написанный на GO.
Но если внутри терминала, где данные есть и доступны всегда, то колбек (именно в этой реализации что есть в Квике) не является единственным и идеальным решением.
11.04.2026 11:43:31, Nikolay.