Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
Пользователь
Сообщений: Регистрация: 12.05.2020
09.04.2026 10:46:48
Цитата
VPM написал: В моем нынешнем варианте (который пытаюсь довести "до ума") скорость цикла main делаю адаптивной к загрузке очереди.
Можно сделать паузу адаптивной к длительности основного цикла скрипта (это учтет все, в том числе и длительность обработки очереди):
Код
run = true
function main()
local function GetMilliseconds() -- Милисекунды с 1970г.
local dt = os.sysdate()
return os.time(dt) * 1000 + dt.ms
end
-- Коды инициализации скрипта --
local pause = 20
local TT = GetMilliseconds()
-- Основной цикл скрипта (while run do)--
while run do
-- Выполнение пользовательского кода --
-- Адаптивное ожидание (динамически зависящее от длительности пользовательского цикла обработки)
local tt = GetMilliseconds() - TT -- Длительность пользовательского цикла обработки
tt = tt >= pause and 1 or pause - tt
sleep(tt)
TT = GetMilliseconds() -- Начало обработки пользовательского кода
end
end
Пользователь
Сообщений: Регистрация: 12.05.2020
09.04.2026 10:53:31
Уточнение: у меня в роботе устанавливается разрешение таймера: 1 млс.
Пользователь
Сообщений: Регистрация: 15.06.2023
10.04.2026 14:23:07
TGB, Спасибо, идея понятна обязательно опробую у себя!
написал: , Кажется уловил Вашу идею, все дело в буффере. Именно он опять возвращает в событийную модель через опрос + буффер, вместо callbacks + буффер? И решаются вопросы тайминга?
Вы можете просто ждать колбека. А можете постоянно опрашивать таблицу. Именно, что постоянно. Естественно через проверку числа записей в таблице как триггер. На вопрос - это же накладно. Ответ - большую часть времени скрипт ничего не делает, так что проверить число записей в таблице - это можно сказать что ничего.
На самом деле все совершенно иначе. Колбек тем и хорош что его не надо ждать. Он вызывается событием. Разница огромная если есть множество инструментов. ---------------------------- 1) Например, колбек OnOrder уже содержит класс и имя инструмента. т е если состояние заявки изменилось, то получим в скрипте уже готовую информацию об инструменте и состоянии. Если же лазить в архив или таблицу, то сначала колбек туда поместит изменение состояния заявки, а потом функция SearchItems (лезет в архив) или getItem (лезет в таблицу) будет перебирать все данные и фильтровать их. Обращение к архиву не быстрая операция. 2) Если колбека нет, то и телодвижений никаких нет. А при опросе архива SearchItems это делается на каждом цикле main есть событие или его нет.
Пользователь
Сообщений: Регистрация: 27.01.2017
11.04.2026 11:43:31
Цитата
nikolz написал: На самом деле все совершенно иначе.
Это не все иначе, а просто другой подход. Есть колбеки - ок. Используйте. Никто не мешает. Но это не означает, что нельзя делать иначе. Я привык делать как опрос датчика, например температуры.
А колбеки я использую если данные из Квика обрабатываются через межсетевое взаимодействие. Например тот же торговый алгоритм, написанный на GO. Но если внутри терминала, где данные есть и доступны всегда, то колбек (именно в этой реализации что есть в Квике) не является единственным и идеальным решением.
Пользователь
Сообщений: Регистрация: 02.01.2026
11.04.2026 12:17:08
Цитата
TGB написал: можно реализовать проверкой (с использованием trans_id) в таблицах order, stop_order. И эту проверку надо выполнять только, когда изменяется количество записей в них.
Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
Пользователь
Сообщений: Регистрация: 02.01.2026
11.04.2026 12:42:58
Цитата
TGB написал: Можно сделать паузу адаптивной к длительности основного цикла скрипта (это учтет все, в том числе и длительность обработки очереди):
А что это даёт?
Пользователь
Сообщений: Регистрация: 27.01.2017
11.04.2026 13:33:43
Цитата
Йцукен написал: Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.
написал: Изменение параметров заявки не приводит к изменению количества записей в таблице. Об этом вы узнаете только через колбэк, либо через регулярный опрос уже существующих записей в таблице.
Да. Датчик температуры ничего не скажет об её изменении. Спросите - скажет.
При чём тут датчик температуры? Если уж приводить аналогию, то, чтобы узнать изменение температуры отслеживаемого датчика, не нужно проверять изменение количества датчиков, а нужно опрашивать конкретный датчик.
Пользователь
Сообщений: Регистрация: 27.01.2017
11.04.2026 19:13:46
Он и опрашивается, через запомненный индекс записи в таблице. Когда ордер найден в таблице, то повторно его иска не надо, просто получить запись в таблице с свежими данными.
Пользователь
Сообщений: Регистрация: 02.01.2026
11.04.2026 21:04:36
Цитата
Nikolay написал: Он и опрашивается, через запомненный индекс записи в таблице. Когда ордер найден в таблице, то повторно его иска не надо, просто получить запись в таблице с свежими данными.
В цикле вы дергаете getItem, независимо от того, изменились ли параметры заявки (заявок) или нет?
Это не все иначе, а просто другой подход. Есть колбеки - ок. Используйте. Никто не мешает. Но это не означает, что нельзя делать иначе. Я привык делать как опрос датчика, например температуры.
А колбеки я использую если данные из Квика обрабатываются через межсетевое взаимодействие. Например тот же торговый алгоритм, написанный на GO. Но если внутри терминала, где данные есть и доступны всегда, то колбек (именно в этой реализации что есть в Квике) не является единственным и идеальным решением.
Не против использования таблиц. сам делал робота в скрипте индикатора и там использовал именно таблицы, так как это проще и в индикаторах нет колбеков. Вы же объясняете почему Вы так делаете. Я тоже объяснил почему колбеки быстрее работают.
Реальный временной интервал циклов обработки без этого: pause + tt (время ЦП обработки цикла). При этом реальный интервал циклов обработки: 1) pause, если tt - 1 < pause. 2) tt + 1, если tt - 1 >= pause. Надо ли это использовать, дело ваше.
2.
Цитата
Йцукен написал: В цикле вы дергаете getItem, независимо от того, изменились ли параметры заявки (заявок) или нет?
Для просмотра изменений в заявках не надо перебирать все записи orders, stop_orders. Достаточно во вновь получаемых сделках (по изменению размера) таблицы traders выбирать trans_id (или номера ордеров) и просматривать только соответствующие заявки. ----- У меня доступ к таблицам прямой, кэшируется (неизменяемое в таблицах) и затраты на обращение к ним мизерные.
Пользователь
Сообщений: Регистрация: 12.05.2020
12.04.2026 15:37:35
Добавление к предыдущему моему комментарию. Иллюзией является представление о том, что коллбеки выполняются параллельно с потоком main. Код скрипта, включая функции коллбеков, разделяется основным потоком QUIK и потоком main. Это значит, что когда выполняется один, то другой блокируется. Переключение потоков происходит только при вызове активным потоком сишной функции (в которой нет автоматического управления памятью Lua). Одной из сишных функций является sleep. Также сишными функциями являются стандартные функции Lua. В основном потоке выполняется много чего, смотрите по ссылке: . При обработке коллбеков основной поток может блокироваться в моменты выполнения в потоке main lua-кода. При выполнении функций коллбеков он также перестает выполнять всю остальную свою функциональность и блокирует выполнение потока main. Поэтому разработчики QUIK рекомендуют создавать между коллбеками и потоком main очереди, а сами коллбеки делать минимальными. В текущей архитектуре QUIK интенсивное использование коллбеков, нагружая основной поток QUIK, как описано выше, негативно влияет на его функционирование и это следует учитывать при написании скриптов. Я написал в ветке по ссылке (пункт 2), что можно бы было изменить в QUIK, чтобы уйти от описанных проблем. Там же, в конце, выложен конкретный вариант, как это можно реализовать, на уровне конкретного работающего кода на C++.
Пользователь
Сообщений: Регистрация: 02.01.2026
12.04.2026 22:34:25
Цитата
TGB написал: Для просмотра изменений в заявках не надо перебирать все записи orders, stop_orders. Достаточно во вновь получаемых сделках (по изменению размера) таблицы traders выбирать trans_id (или номера ордеров) и просматривать только соответствующие заявки.
