Система принятия решений и/или Нечеткая логика(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, независимо от того, изменились ли параметры заявки (заявок) или нет?
