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

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

А что сравнивать, если они для разных задач предназначены?
Кольцевой буфер - для хранения ограниченного количества элементов. Индексация всё время сдвигается вправо. Возможно удаление и изменение элементов с любым индексом.
Очередь из сообщения #699 аналог обычной таблицы с индексацией, начиная с 1. Используется, когда надо удалять элементы в начале таблицы, т.к. table.insert с этой задачей плохо справляется.

Так ведь и двойная очередь ограничена количеством элементов, для этого и храним первый и последний индекс. Лично меня всегда смущает в кольцевом буфере не явная индексации, "под ложечкой ноет" а тот ли элемент получен в расчетах. В то время как в двойной все линейно.

    Из написанного вами о двойной очереди (по сути реализующей одну) я не понял между какими функциональностями робота они могут использоваться и что при этом не обеспечивается в QLua, выложенным мной давно известным вариантом?

Извлечь нет, а вот размер уже можно получить кривой. Плюс надо как-то гарантировать, что в двух потоках не будут разбирать очередь. Можно надеяться, что так не напишут, но это не гарантия, т.к. блокировок нет.
Хотя можно завернуть код в table.ssort

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

Потому что в момент получения размера, другой поток изменит last или first

-- Текущий размер очереди ---
function QueueSize(self)    return self.last - self.first + 1  end

Не факт

Я говорю, что сомнительно, что то, о чём вы пишите, вообще может произойти в Lua 5.4. Потому что там байт-код, который по определению выполняется под блокировкой.

Nikolay, а для чего вам знать размер очереди? Вы же не извлекаете из середины?
Если организуется FIFO, то берётся первый элемент из очереди до тех пор, пока там что-то есть.

Думаю, что для qlua такой проблемы вообще нет. Не те скорости. Это просто был пример для более тяжелых систем, не более.

Или вот это, До обсуждались, про супер: А Не смущает то что мы ее задаем и вынуждены контролировать? Постоянно так Quik Ни чего нигарантирует?

Для чего?

  В ветке "Что стоило бы изменить в QUIK по-крупному" (от 15.03.2024) предложены изменения схемы встраивания Lua в QUIK (с сохранением существующего API пользователя) устраняющие некоторые существующие его дефекты, но реакция разработчик QUIK нулевая. Нет даже возражений.

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) верны, а архитектура действительно гарантирует безопасность счёта при любых мыслимых сценариях работы биржи и сети.

И это совершено иная концепция безопасности. "Ни гадать а быть уверенным"!

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)

   Config = require("config")
   Logger = Logger:new(Config.log)
   RiskManager = RiskManager:new(Config.risk)
   Strategy = MeanReversionStrategy:new(Config.strategy)
   Adapter = QuikAdapter:new()
   Core = TradingCore:new{
       strategy = Strategy,
       risk = RiskManager,
       adapter = Adapter,
       logger = Logger
   }

   Logger:info("System initialized")
end
Это наглядно, контролируемо и соответствует production-подходу.

3.2. Загрузка сохраненного состояния (persisted state). В OnInit удобно:
* восстанавливать позиции;
* читать журнал;
* восстанавливать FSM состояние;
* загружать последние известные заявки (last known orders)

3.3. Регистрация системных обработчиков. Можно централизованно регистрировать:
* OnOrder
* OnTrade
* OnStop
* Watchdog

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 подходе. Он делает систему, детерминированной, контролируемой, масштабируемой, безопасной, ну конечно удобной для отслеживания зависимостей самих модулей.

   Я бы не стал это комментировать, но ведь кто то может это воспринять как открытие  и руководство к действию.
 Попробую объяснить ваше заблуждение (очередное).
Я в своих скриптах не использую ни OnInit ни кода в body по следующим причинам:
1) Код OnInit и код body будут исполняться в основном служебном единственном потоке, который обслуживает:
  - запуск всех Lua-скриптов пользователя;
  - запуск коллбеков всех Lua-скриптов пользователя;
  - обработка всех коллбеков таблиц QUIK (это не таблицы Lua);
  - обработка всех индикаторов пользователя.
 Это значит, что пока он будет "возиться" с кодами OnInit и  body другого он ничего делать не будет.
  На всякий случай попробуйте в начале OnInit написать строку: sleep(30000) и посмотрите что получится .
2) Всю необходимую инициализацию (включая пакеты) можно разместить в начале main в виде функции, вызываемой сразу после ее определения и это будет выполняться в отдельном созданном потоке main, а основной служебный поток продолжит параллельно (если у ПК несколько ядер) выполнять свою перечисленную ранее работу.
3) в рассмотренном варианте при запуске нескольких скриптов сразу они начинают выполняться быстрее, чем с кодами в OnInit и  body.

TGB,  Ну Вы опять, как школьник вызубривший урок наизусть, и ни грамма отступить от догмы, ну как тут не поверить, что перед нами отличник?

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

Но разве разговор про это? Ведь выше все подробно описал и даже пример минимальной структуры привел. Найдите там блокирующее body?

В кои веке, удалось найти что QUIK, что однозначно гарантирует. Ничего не произойдёт в скрипте пока OnInit не просигнализирует.

Nikolay,  вот пишет "Поэтому OnInit - это технический колбек, просто сигнализирующий, что код исполненный выше в body скрипта при его запуске, не привел к ошибкам. Ничего более. Делается это один раз при запуске. Поэтому там и могут быть только сугубо технические действия именно при запуске скрипта и ничего более."

Это как фазовый гарантированный переход! Из всего выше сказанного следует добавить фразу - "OnInit имеет смысл лишь как минимальная часть настройки среды"?

Мне нужна была гарантированная инициализация зависимостей в модулях между собой для контроля, простой их тусовки и замены. Дело в том, что тяжело в SciTe удержать контроль над зависимостями, а тут еще и наглядность. Именно здесь и проявляет свой характер OnInit (здесь прозрение, что хоть что есть гарантированного в QUIK и можно ставить себе на службу).

Nikolay,  Ваши замечания как всегда точны и логичны. Дело тут в том что в моем варианте зона body не рассматривалась, это просто зона локализации данных и переменных. Ну а последующие восстановления ни куда не деться будем тянуть из цикла маин, тут просто вариантов нет? Или я опять что то упускаю из вида?