Nikolay (Все сообщения пользователя)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 25 След.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Все же мне сложно понять зачем выбирать чтение с медленного графика, когда есть инструмент для получения данных без каких либо ручных манипуляций. Да и сама реализация опять через какие-то блокирующие циклы, ожидания. Клиент-серверные системы так не реализуются.

Если хотите полный контроль над данными и полную синхронность, то просто рассчитывайте бары сами. Берете таблицу обезличенных сделок, читаете и строите бары любых ТФ. При этом, т.к. поток для расчетов один, то и разные бары будут получены в одно время. Т.е. это уже часть вашей архитектуры, а не зависимость от API Квика. Более того, такой способ позволит получать много дополнительных метрик, которые просто не доступны для баров Квика. Собственно очень многие сторонние системы, подключающиеся к Квику, так и работают - расчет по сделкам, дамп закрытых баров в кеш (файлы, базы данных). В итоге данные на истории всегда есть, получаете только новые бары. Также такой подход позволит оценивать систему в любой выбранной точке на истории без необходимости что-то заказывать в Квике. А если это сторонняя система, то и не открывая Квик.
Окно «Ввод заявки», Ввод цены «По доходности»
 
Цитата
Oleg Kuzembaev написал:
Параметр "Доходность" выражен в процентах.
Тогда объясните эти цифры.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
 У баров есть единое пространство - это время. Индекс бара ничего не говорит, он не подходит для этих целей. Поэтому синхронизировать данные необходимо по шкале времени наименьшего ТФ или по наибольший общий делителю. При этом, т.к. бары могу быть построены по любым данным, то и ТФ может быть любым, например 30 секунд. В итоге, определяем квант времени, а далее по мере прихода данных происходит их обработка.
При этом если есть ТФ не кратные друг другу, то обработка может быть не синхронной, например бары 2 и 3 минуты. Будут моменты когда приходит бар 3 минуты, а бара 2 минуты нет и не будет в это время.

Ничего сверхъестественного. По большому счету это, то как глазами видят картину. Смотрим на графики и видим текущее состояние (или сдвинув графики на точку времени) и производятся действия в этой точке времени. Синхронизация не зависит от Квика и его особенностей. Представьте, что одновременно обрабатываете данные из Квика или API MOEX, API NYSE, API LME и API SEHK. Совершенно разные источники, разные соединения, разные задержки. И при этом работать же надо, а не говорить - это сложно, не будем.

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

Более важен вопрос - а надо ли это делать. Банально иногда нет причин. Выбрали один источник данных, с помощью которого получаете 90% данных, и реализовать работу с ним. А если надо будет получать данные иначе, ну добавите несколько методов, чтобы считать через него. У меня в скриптах внутри Квика все получается через CreateDataSource. Иногда через таблицу сделок для ТФ меньше минуты. Или чтение из csv файлов. Все это загоняется в простейшую таблицу у которой __index может ссылаться на ds, если он есть. И реализованы простейшие прокси методы повторяющие методы ds из CreateDataSource. Вот и есть универсальный контейнер. Если хотите использовать getCandlesByIndex - ничего не мешает, просто реализуйте методы O C H L Size Close. И получите единый интерфейс к данным. Но когда в скрипте нет задачи собирать данные, то проще и быстрее сделать напрямую. В конечном итоге - зачем выполнять лишний код.

Но, как написал выше - если это необходимо. Иногда все эти сказки из книг типа "Чистый код" - это теоретические изыскания, не имеющие никакого значения на практике, т.к. делают код очень медленным, объемным.
Окно «Ввод заявки», Ввод цены «По доходности»
 
Ок. Но тогда просьба пояснить в каких единицах выражается поле доходность. Явно не проценты.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Так как я не представляю портфель с 1000 тикеров
А причем здесь портфель? Это чисто техническая задача - получение данных баров для инструмента. Их можно получить из Квика, можно через API биржи, из других ресурсов, даже из своего кеша, чтобы каждый раз не делать запрос на все данные, ради одного нового бара.

Но если она решается через получение данных с открытого графика, то это накладывает условия для работы - необходимо открыть график для каждого ТФ, каждого инструмента.

Если даже инструментов 10 и три ТФ, то это 30 открытых графиков с назначенными идентификаторами. И все это руками. И нельзя ничего с этими графиками сделать в процессе работы скрипта.
Очень странное решение при наличии независимого источника данных, не требующего никаких условий, кроме наличия потока от брокера по инструменту.

И я уже не раз замечаю, что Вы смешиваете техническую реализацию интерфейса с логикой обработки данных из интерфейса. Как я выше написал, источников может быть много, к ним есть интерфейсы, и единая логика обработки. Т.е. как получены данные (через какую трубу), никак не должно влиять на логику. По этому инструменту из кеша, по другому из интернета, а по третьему из Квика - не важно. Данные должны быть представлены в едином виде - класс данных. И уже работать с ними единообразно.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Конечно нет ни какой необходимости открывать 1000 графиков
Если скрипт сканирует один инструмент, то возможно. У меня же есть скрипты одновременно собирающие данные по все инструментам разных классов. И это в терминале где не открыто ни одно окно. Это сотни инструментов в одном скрипте. А т.к один график - один инструмент, то, спрашивается, где же взять данные.

Цитата
VPM написал:
Делаю так:

Это и есть блокирующие ожидание. Причем невозможно ответить на вопрос - пусто потому что график еще не открылся (т.к. скрипт запустился раньше) или просто ошибочный таг, или данные с сервера едут. У меня, например, один брокер очень долго строит график по облигациям. Открываешь график - а там пусто. Через минуту появились бары. Все как с CreateDataSource.

Частично вопрос об ошибочном таге можно снять, если вызывать TABLE t, NUMBER n, STRING l  = getCandlesByIndex, т.к. она возвращает - l (подпись). Если ошибка в таге, то подпись будет пустой.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
и все что беспокоит это "дыры" в данных
Я написал основные проблемы при чтении с графика. И это только самые очевидные. Дыры - это не проблема, т.к. обрабатываются точно также. Плюс удобство работы вызывает сомнения, т.к. чтобы эта конструкция работала необходимо держать открытыми графики. У меня скрипты могут сканировать до 1000 инструментов на разных ТФ - предлагаете все это открывать, наносить индикаторы. Терминал умрет первым.

И в подходе с CreateDataSource, как уже обсуждали, нет никаких бесконечных циклов ожидания. Точно также - заказ, и сразу возврат. А фоне висит задача проверки загрузки данных. И все это будет работать в пустом терминале, не не открыто ни одно окно, за ненадобностью.

Если думаете, что getCandlesByIndex не требует ожидания и проверки, что данные есть, то ошибаетесь. Точно также требует. Да, если скрипт запускается уже после того как терминал загрузился и "прогрелся", то можно ожидать, что данные уже есть. Но полностью исключает вариант работы скрипта "не выключаясь". А с таким числом требуемых графиков, терминал будет стартовать долго.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Это потенциально бесконечный цикл. Достаточно ошибиться в таге источника. Ожидание необходимо организовывать точно также, как рассматривали ранее. В этом плане getCandlesByIndex совсем ничем не отличается от CreateDataSource.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Для меня метод getCandlesByIndex применим только в одном единственном случае - есть некий индикатор, алгоритм которого не формализован, поэтому нет другого способа получить данные расчета в точке времени, либо необходимо вывести данные с графика другого ТФ. Во всех остальных случаях читать данных через CreateDataSource надежней. Т.к. используя getCandlesByIndex, необходимо решать много вопросов - при открытии терминала скрипт запустится быстрее чем терминал обновит графики, или читающий индикатор загрузился первым, а источник потом; если случайно сменить инструмент или ТФ на графике, то необходимо корректно это обработать, чтобы алгоритм читающей стороны не "сходил с ума"; да и скорость появления данных на графике - самая медленная.

Так что причин использовать getCandlesByIndex не так и много. Хотя, конечно, если лень заниматься реализацией алгоритмов, то да, читаем и надеемся на лучшее.
Окно «Ввод заявки», Ввод цены «По доходности»
 
Простая облигация - там реакции нет никакой. Для ОФЗ вроде есть реакция, но какая-то странная цифра в доходности требуется, чтобы цена изменялась 1000 и более. Что здесь тогда подразумевается под доходностью?
Окно «Ввод заявки», Ввод цены «По доходности»
 
В релизе 12.6.0.53 указание доходности и выполнение команды "Задать цену" не приводит к изменению цены. Какую бы доходность не указать.
Разрыв соединения quik по ночам, Приходится каждое утро переподключаться
 
Конкретно для брокера Сбер - это так. Впрочем и для большинства брокеров, они ночью запускают регламентные операции на серверах.
У других брокеров просто нет SMS аутентификации, что позволяет автоматически восстановить соединение скриптами.
Как создать мост QLua-скрипта с другим C++ приложением? Вопрос концепта., Предлагаю такой подход, но есть вопросы.
 
Еще забыл про такое решение https://github.com/devslm/quik-connector в качестве транспортной шины данных используется Redis
При смене инструмента графика в Lua индикаторе OnDestroy() не вызывается
 
Вы уже определитесь ошибка ли это или нет. А то здесь уже обещали исправить https://forum.quik.ru/messages/forum10/message79698/topic2730/#message79698
CreateDataSource
 
Цитата
Сергей Че написал:
А разве может быть ошибка при вызове   Close()   для  непустого  data_source?
Конечный пользователь, опирающийся на руководство  QLua , вообще не должен быть в курсе о внутренней кухне (кешируется там что-то или нет).
Есть функция   Close()  , значит она должна всё корректно закрыть.
Во-первых, он уже может быть закрыт. А у Вас ссылка сохранена. Во-вторых, если этот поток в кеше был выдан по другому запросу, в вашем примере это другая таблица sec, то закрывая поток, об этом не узнаю другие пользователи этого потока.

Эта задача, похожа на задачу GC. Есть ссылка, её используют несколько потребителей. Соответственно закрыть ссылку можно только если счетчик использования 0.
CreateDataSource
 
Цитата
Сергей Че написал:
sec.data_source:Close()
Зачем закрывать, если он уже есть. Наоборот, просто вернуть существующий.
Если закрыть поток, который в кеше и используется, то будет ошибка обращения.
CreateDataSource
 
Здесь вопрос более тонкий. Кеш сделали и ладно. Я бы не стал полагаться на GC, все же запомнить уже заказанные потоки не сложно.
А вот закрытие оных уже вопрос. Я меня есть счетчик использования потоков. Т.к. один и тот же может использоваться много раз. И по мере того, как он перестает быть необходимым счетчик уменьшается, и если он 0, то вызывается Close. Дабы закрыть поток.

Но т.к. скрипт может быть остановлен принудительно, что закрыть все открытие потоки уже не всегда будет возможно. Как себя ведет терминал при таком закрытии скрипта - не ясно. Надеюсь, что есть внутренний кеш.. В древних версиях терминала (на ранней 7-ой, кажется) при заказе потоков без закрытия или вызова GC - терминал начинал есть память.
CreateDataSource
 
Если не путаю, то кеширования нет, так что это задача скрипта помнить, что уже заказано.
Использование нескольких торговых счетов в одном Квике
 
Субсчет в рамках счета - один квик, например в Альфе, Кит так. Разные счета (не ИИС к брокерскому - это в одном терминале) - это уже зависит уже от брокера. Сбер, например, недавно всех загнал в один терминал. У меня в Сбере два брокерских счета - в одном терминале.
Как создать мост QLua-скрипта с другим C++ приложением? Вопрос концепта., Предлагаю такой подход, но есть вопросы.
 
У qluacpp есть форк https://github.com/Arech/qluacpp2

Правда тоже надо пилить напильником. В данном случае проще написать логику через dll на Lua C API.Но если все же смотреть на TCP, то тот же QuikQtBridge (https://github.com/eSKond/QuikQtBridge) написан на С++, правда с использованием Qt (для сетевой части). И он мне больше нравится, чем QUIKSharp, т.к. у оного сервер, по факту, написан на Lua. Если задача построить только серверную часть, то можно и взять только её.
Как создать мост QLua-скрипта с другим C++ приложением? Вопрос концепта., Предлагаю такой подход, но есть вопросы.
 
Решения через Socket уже есть: QUIKSharp и QuikQtBridge. Еще есть StockSharp, но много нареканий на него.
Также есть RPC вариант - quik-lua-rpc
Был еще прямой интерфейс на c++ (но уже давно не поддерживается): qluacpp

По названиям легко найдете репозитории.
Какой ИИ адекватно пишет
 
Вопрос некорректен, т.к. на чистом Lua любая пишет адекватно, правда чтобы избежать галлюцинаций, необходимо указывать что можно использовать, иначе может придумать методы, например из Питона.
Вы же хотите код на qLua, т.е. использовать методы терминала о которых мало что известно им. Точнее что-то они знают, но именно что-то.
Поэтому прежде чем задавать вопрос, загружайте документацию qlua, чтобы был понятен контекст разработки.

А так - Anthropic Claude, если есть доступ. Если нет, то OpenAI с их ChatGPT. Если и к ним нет, то и DeepSeek сгодится, если правильно вопросы задавать.
Вопрос по ленте сделок, Вопрос по ленте сделок
 
Не зная какие это сделки нельзя сделать вывод о изменении ОИ. Если сделки между новым и выходящим контрагентом, то ОИ не изменится. Да и 400 контрактов - это что-то мелкое.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Если это написал очередной чат, то результат ожидаем. У половины методов нет определения. В целом, на данный момент задавать им вопросы по написанию кода связанного с статистикой и временными рядами - плохая идея, если это не Питон. Он пытается вставить несуществующие методы, придумать их, думаю что мир устроен одинаково - в Питоне же есть, значит и везде есть.

Если задача показать разные методы, то проще дать ссылку на статью, где все они формализованы. Сейчас все разучились искать, так что я прямо обратно в 94-ом, когда интернет был набором каталогов с ссылками.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
В части анализа данных, с нормализацией данных не все так просто.
Приведение данных к единообразным границам, да. Но также есть те, где обеспечивается сигма = 1, выбор точки среднего около 0, например Z-нормализация.

Приведенный же Вами MaxAbsScaler - очень наивен и прост. Выбор алгоритма масштабирования данных производится после анализа временного ряда.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
сравните
Э... Возникает вопрос - а когда подписка закончена, этот код что будет делать на постоянные вызовы OnParam? Да и нагрузка на сам колбек основного потока, хоть и небольшая, но есть. Плюс, если инструмент малоликвиден, то подписка на данные когда произойдет? Иногда ведь надо получить данные, что-то рассчитать и закрыть поток. И надо это сейчас, а не когда через часы будет изменение ТТТ.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
он дергается основным потоком ровно тогда когда тот запихивает данные в хранилище.
Если нам не надо реагировать на незакрытую свечу, то в колбеке просто ее игнорируем.
Я же написал, что для меня - это лишние телодвижения. Нет желания разбираться какой это вызов колбека, холостой на истории или по закрытию бара, или по сделкам внутри бара. Я точно также одним if сравню последний размер выборки с текущим. Плюс уже просто личные субъективные предпочтения - не использую колбеки основного потока.
Это уже дело вкуса. Но как говорится, кому-то подавай ООП со всеми излишествами, мне же простой C - лучший выбор.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
А если поставить колбек то и тыкать не надо. Тратим время лишь когда приди данные. Что не так?
Не так, что этот колбек будет вызываться на всех барах истории, начиная с 1. Также он будет дергаться на каждую сделку. Это все лишние телодвижения. По крайней мере мне необходимо пройтись по последним, скажем 100 барам, а далее один раз на новый бар. Но да, можно и так, если организовать доп. проверки в этом колбеке.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Так и в нашем упрощённом варианте предусмотрен выход из цикла подписки.
Может я, конечно, невнимательно смотрел примеры, но все одни предполагали ожидание через цикл. Т.е. заказали - и тут же ждем. В итоге заказ 100 источников растягивается во времени, т.к. последний будет заказан только через 100*время ожидания. Что долго. Подход заказали все сразу в цикле и потом ждем все в цикле лучше, но тоже заблокирует скрипт пока ждем циклом. Здесь же заказ всех сразу. И периодически просто атомарно  "тыкаем палочкой" на предмет данных. Пришли - можем делать что-то с данными. Нет - переходим к другим задачам, а эта пока путь остается. Т.е. ожидание не мешает другим задачам не связанным с данными, коих может быть много в скрипте.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цикл for i = 1, #sec_list do - это просто пример организации заказа данных. Он выполняется однократно и ничего не блокирует. С тем же успехом можно было бы вставить где-то в другом месте вызов заказа данных.

Единственно, что можно изменить - это более ранний выход из процедуры обработки задач, чтобы проход по очереди задач был однократный за вызов.

       count = count + 1
       if count > #task_queue then
           if #task_queue == 0 then print('Очередь задач пуста') end
           return
       end
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Я не понял комментарий. Есть контекст. В нем открываем ds и запускаем задачу. У ds есть признак done_request.
В очередь задач кидаем функцию проверки размера. Эта задача ничего не блокирует, т.е. можно в рамках контекста выполнять другие задачи, например, обработать сделки, совершенные пользователем, команды интерфейса и т.д.
А процедура, которая зависит от ds, просто ждет когда признак done_request изменится.

Код
В Вашем подходе будет все висеть пока все тикеры не подпишутся

Что будет висеть? Вызов Dispatch() - это один из методов main, коих может быть бесчисленно число. Т.е. обработали задачи, какие-то завершились, а какие-то нет. Но это не значит, что висит, просто переходим к дальнейшему выполнению main, после возврата из Dispatch(), т.к. он не блокирующий. В нем просто перебираем накопившиеся задачи и выходим после прохода по очереди.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Поясните?

Подпиской создали таблицу интерфейса для получения данных, а дальше в потоке луа получаем ds:O(I).

Вы так восторгались корутинами, что подход запрос -> чтение ответа через вызов-проверка должен быть очевиден. Самое главное - у нас нет понятия сколько времени займет приход ответа. Может 100 млс, а может 5 минут.
Поэтому нельзя использовать любые подходы с циклами ожидания с какой-то заданной величиной. Да, необходима какая-то отсечка по времени, чтобы отсекать проблемные запросы.

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

Также стоит учитывать, что простая проверка размера ds:Size() - это слишколм просто. Я проверяю время последнего бара и время последней сделки, чтобы избежать порционного получения данных, когда размер уже не 0, но он еще не последний.
Код
local is_run = true

if _G.message then
    print = function(...) _G.message(table.concat({...}, ", ")) end
end

local task_queue = {}
local function AddActionResult(task, is_done, is_error, mes)
    if not task then return end
    if is_done then
        task.done         = true
        task.error        = false
        task.response_mes = tostring(mes or '')
    elseif is_error then
        task.done         = false
        task.error        = true
        task.response_mes = tostring(mes or '')
    end
end

local function Process(task)
    if not task then return end
    if not task.process then return end
    if not task.in_progress then task.in_progress = true end
    AddActionResult(task, task.process())
end

local function Dispatch()
    if not is_run then return end

    local count = 1
    while is_run and #task_queue > 0 do
        local task = task_queue[count]
        if task and not (task.done or task.error or task.stop) then
            Process(task)
        end
        if task and (task.done or task.error or task.stop) then
            task.in_progress    = false
            local response_mes  = ''
            if not task.silent or not task.done then
                if task.done then
                    response_mes = 'Задача выполнена успешно: '..tostring(task.description)
                elseif task.error then
                    response_mes = 'Задача не выполнена: '..tostring(task.description)..', по причине: '
                elseif task.stop then
                    response_mes = 'Задача остановлена: '..tostring(task.description)
                end
                print(response_mes)
                if (task.response_mes or '')~= '' then                    print('\t'..(task.response_mes or ''))
                end
                if type(task.done_callback) == 'function' then task.done_callback(task) end
                if type(task.err_callback) == 'function' then task.err_callback(task) end
            end
            table.sremove(task_queue, count)
            count = count - 1
        end
        if count + 1 >= #task_queue then
            if #task_queue == 0 then print('Очередь задач пуста') end
            return
        end
        count = count >= #task_queue and 1 or count + 1
    end
end

local function create_ds(ctx, done_callback, err_callback, wait_time)
    if not ctx then return end

    local ds, err = _G.CreateDataSource(ctx.class_code, ctx.sec_code, ctx.interval)
    if not ds then
        print(err, 3)
        return
    end

    ds.interval     = ctx.interval
    ds.class_code   = ctx.class_code
    ds.sec_code     = ctx.sec_code
    ds.description  = ctx.class_code..'|'..ctx.sec_code..', интервал '..tostring(ds.interval)
    ds.done_request = false
    ctx.ds          = ds

    print('Заказ данных '..ds.description)

    wait_time       = wait_time or 60
    local lt        = os.time()

    local task = {description = 'Заказ данных '..ds.description, ctx = ctx}

    task.process = function()
        if os.time() - lt >= wait_time then return false, true, 'Не удалось инициализировать инструменты за время '..tostring(wait_time)..'сек.' end
        local size = ds:Size()
        if size == 0 then return end
        ds.done_request = true
        return true, false, 'Получены бары '..ds.description..', размер: '..tostring(size)
    end
    task.done_callback  = done_callback
    task.err_callback   = err_callback

    task_queue[#task_queue+1] = task
end

local function counter(i, limit)
    local x = 0
    local task = {description = 'Счетчик до '..tostring(limit)}
    task.process = function()
        x = x + 1
        if x >= limit then
            return true, false, string.format('%i: Счетчик до %i завершен', i, limit)
        end
    end
    task_queue[#task_queue+1] = task
end

local  sec_list = {}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'SBER', interval = 1}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'SBER', interval = 2}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'SBER', interval = 5}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'SBER', interval = 10}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'SBER', interval = 20}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'GAZP', interval = 10}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'GAZP', interval = 2}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'GAZP', interval = 5}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'LKOH', interval = 5}
sec_list[#sec_list+1] = {class_code = 'QJSIM', sec_code = 'FEES', interval = 5}
sec_list[#sec_list+1] = {class_code = 'SPBFUT', sec_code = 'SiZ5', interval = 5}
sec_list[#sec_list+1] = {class_code = 'SPBFUT', sec_code = 'RIZ5', interval = 5}
sec_list[#sec_list+1] = {class_code = 'SPBFUT', sec_code = 'RIZ5', interval = 15}
sec_list[#sec_list+1] = {class_code = 'SPBFUT', sec_code = 'SRZ5', interval = 30}

function main()
    for i = 1, #sec_list do
        counter(i, i*2)
        create_ds(sec_list[i])
    end
    while is_run do
        Dispatch()
        sleep(100)
    end
end

function OnStop()
    is_run = false
end

В итоге можно заказать много потоков, но пока не принято решение, что данные получены, есть задача проверки. И не важно сколько времени это займет. Также и с транзакциями. Например, сегодя с утра один из брокеров обрабатывал транзакции 2 минуты, хотя обычно менее секунды. Но т.к. нельзя сказать сколько времени займет процедура запрос-ответ, то и просто ждать 30 секунд нельзя. Да и 2 минуты нельзя, т.к. завтра может придется ждать 5 минут.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Минимально безопасный вариант
Да причем здесь безопасность. Вы работаете а терминале - это клиент для сервера. Его задача показать данные, приходящие с сервера. И отправлять запросы на сервер. Все.

Можно абстрагироваться и сказать - есть база данных где-то в сети и есть клиент (браузер), показывающий данные. Задача показать данные из 1000 таблиц. Одна таблица - один запрос. Данные могут приехать за 10 млс., а могут за пару минут. Время не угадать.

Поэтому такого рода задачи решаются через запрос, запрос, запрос.... Ответ, ответ, ответ, таймаут, ответ... А не запрос-ждем, запрос-ждем... и последний запрос будет через бесконечность.

Т.е. кидаем запросы атомарно, создаем задачу для проверки ответа. В других языках можно было бы организовать AsynсAwait для ожидания ответа в фоне, пусть приходит ответ когда придет, а пока будем выполнять другие задачи. В Luа же проверяем ответ опросом созданных задач. Пришли данные - фиксируем, переходим к следующему. Не пришли - выполняем другую задачу. И так пока не придут все данные и мы не очистим очередь задач, опрашивая их. Вы же только что сами писали про магию корутин, а здесь забыли про это.

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

Такое ощущение, что все забыли как работала связь в 90-х. Тогда речи не было о млс. Минуты.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
TGB написал:
Ее легко изменить для запроса данных по многим тикерам:   Параметром при этом может быть таблица со списком class_code, sec_code, tf.   В цикле запрашиваются ds, а затем в цикле выполняется проверки поступления данных (как это делается в выложенной функции) и выдается результат в виде таблицы параметра с добавленным полем ds.
Это все равно будет блокирующая реализация, т.к. просто будете ждать в цикле. Закажете сразу, да. Но выйдете из метода только после ожидания. А по хорошему, заказ - это атомарное действие и проверка - это атомарное действие.
Не пришли данные - переходим к другим действиям, может по какому-то инструменту надо транзакцию отправить.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
TGB написал:
Функция запроса данных свечей по тикеру с учетом возможных задержек
Просто к слову - это блокирующая реализация. По опыту, данные могут приходить долго. Поэтому я предпочитаю подход через неблокирующие задачи. Сразу заказывается много потоков, хоть 1000. А потом просто проверяем, что данные приехали, опрашивая задачи.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Следовательно  ds:Size() = 0, есть показатель того что брокер не отдает данные?  
К сожалению нет, т.к. это просто признак, что данных пока нет. Но они могут появится. В этом плане Квик очень скуден в плане определения статусов серверных запросов.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Моя идея была получать разные параметры единообразным способом, в формате свечей, что в свою очередь позволило обрабатывать их едиными способами. Использовать единые фильтры, индикаторы, паттерны. Следовательно формировать единую логику, не только для цены, но и для OI, количества на покупку / продажу и так далее.
По этому поводу я не могу ничего сказать, т.к. чтобы делать такие аггрегации необходимо доказать, что они имеют смысл. Единообразие - это хорошо, но не всегда.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Практика нормальная если предполагать, что она работает всегда. Но т.к. это не так, то значит - не лучшая идея. У меня, например, один брокер отдает такие потоки, но только за прошлые сессии, а за текущую уже нет.
И зачем такой поток, спрашивается.

Здесь важно понимать, что брокер и биржа - это коммерческие организации. А данные - это их продукт. Хотите данных - покупайте. У биржи напрямую, через брокера - не важно. Соответственно свечи по истории изменения быстроизменющихся данных - это доп. нагрузка на инфраструктуру. Кто-то дает и так, кто-то нет. Не готовы мириться с качеством - готовьте сами. Данные есть - аггрегируйте сами, хоть по ТФ = 33 секунды. Если есть хоть какой-то смысл в этом действии. А если видите, что есть пропуски данных (а это будет точно) и это очень важно, то следующий шаг - заказать прямой доступ к серверам брокера через API. Но писать уже будете явно не на Lua. Если и этой скорости мало, то прямо к бирже и аренда серверов с прямым доступом к бирже.

Другой вопрос - а готовы ли к расходам. И стоит ли это вообще делать, т.к. обычно такие скорости нужны для HFT где нужны объемы, которые очень редко доступны для физ. лиц.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
А что брокер под каждого клиента подстраивает сервер? Или как?
Нет, просто не включает многое. Сервера и каналы не резиновые. Тем более, что сейчас уже не модно сидеть перед монитором. А для экранов 5 дюймов много не надо, там и данные можно отдавать раз в секунду - никто не заметит.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Если Вы просто хотели обычный поток баров-свечей, то не надо указывать имя доп. параметра ТТТ 'last' при создании потока.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Возможность создания источника данных по данным ТТТ должна быть поддержана брокером. Многие брокеры не включают избыточные потоки данных по умолчанию. Например, те же обезличенные сделки, т.е. тиковые данные только по запросу. Также и для баров по данным ТТТ. Обычному пользователю это не надо. А кому надо запросит.
Индекс запсииси в таблице ордеров
 
Думаю, что смело можно сказать, что в серверной части Квик есть какой-то "гуляющий" баг. Начиная с 12-ой версии происходят регулярные отключения с последующим вызовом OnCleanUp.

В очередной раз брокер Сбербанк

[INFO  2025-11-13 11:39:33] :           OnDisconnected
[INFO  2025-11-13 11:40:16] :           OnCleanUp
[INFO  2025-11-13 11:40:19] :           OnConnected flag true


[INFO  2025-11-11 19:56:23] :           OnDisconnected
[INFO  2025-11-11 19:56:59] :           OnCleanUp
[INFO  2025-11-11 19:57:05] :           OnConnected flag true


Если бы это был только один брокер, то, возможно, можно было бы списать на его настройки. Но это происходит у разных брокеров с разной периодичностью. Хотя у брокера Альфа пока не было таких случаев вовсе. Но т.к. у него Квик не особо доступен, то, возможно, данное поведение связано с нагрузкой на сервера.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Код
    if self.loaded[cache_key] then
        return self.data[cache_key]  -- Возвращаем из кэша
    end

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

И да, делать для этого объекты - так себе затея.

Входящие параметры для скрипта - это код инструмента, торговый счет, субсчет (код клиента) если их несколько. Все. Остальное получается из терминала. Впрочем даже счет и субсчет можно подставить из данных для класса инструмента. Зачастую они и нужны.

Если Вы пишите скрипты для себя, то, конечно, делайте как хотите. Но если уже для других, то всегда отталкивайтесь, что максимум что может сделать пользователь - это изменить файл настроек, где все максимально просто и понятно. Не надо искать информацию в служебных окнах терминала. Либо делать интерфейс, через который тоже просто задаются параметры.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
мета табличный доступ через "__index"
Это медленно. Объекты нужны там где это действительно надо. А надо это редко.

Как бы вы не обернули и назвали процедуру получения данных из терминала - это все равно будет через один из методов qlua. В данном случае через getParamEx. Можно дополнить кешированием по времени пакета, хотя чтобы его получить тоже придется обратиться к данным терминала.

Квик, к сожалению, не предоставляет удобных методов, позволяющих отслеживать изменение параметров в реальном времени. Точнее - их нет. Есть событие, что что-то изменилось. А что - уже нет. Поэтому вы просто вынуждены читать их сами. И если цикл алгоритма длинный (сам алгоритм или много бумаг), то за время последнего обращения к параметру в алгоритме (именно в нем), сам параметр мог изменится уже 10 раз. Поэтому и чтение последней цены надо организовывать сложнее чем просто в момент принятия решения. Хотя это все зависит от алгоритма, и может достаточно понять что есть именно сейчас.

Цитата
VPM написал:
Кэш + корутина, кэш обновляется асинхронно
И опять про асинхронно. Да не выйдет у вас сделать это полноценно хорошо, т.к. эту корутину все равно надо самому вызвать, чтобы она прочитала данные. Сама она, без вызова, ничего не сделает. Поэтому данные обновятся тогда, когда вернетесь в эту корутину. Сколько раз вызовете, столько раз и обновятся.

Можно использовать колбек OnParam и в нем читать данные, обновляя некую таблицу. А алгоритм уже будет ее читать. И это без всяких корутин. И будет условно "асинхронно", т.к. колбек приходит от терминала, а не по вызову из кода.

Можно написать скрипт, читающий данные, только это. И, например, сохраняющий в in_memorу database или как-то иначе. А других скрипты уже читают это. Т.о. будет действительно некое подобие распараллеливания. Думать о чтении данных не надо - они есть. Хотя это мало чем отличается от прямого чтения через getParamEx, если принимать решение только на базе текущих данных, а не за историю.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Большого это сколько в граммах? Скрипты без интерфейса без проблем обрабатывают тысячу и более инструментов. С интерфейсом 500. Правда здесь стоит учитывать, что для интерфейса желательно задать задержку 50 млс.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
Если их дергать часто, они начинают “затыкать” поток исполнения и могут даже вызывать таймауты при большом количестве бумаг?
Откуда эта информация? Я как-то писал скрипт записи в базу данных состояние стакана. А другой скрипт читал из нее. Для проверки были запущены два скрипта с окнами этого стакана и выведен сам стакан терминала, что банально сравнить визуально данные. Так вот на глаз между тремя окнами очень трудно было заметить различия.

Цитата
VPM написал:
Можно делать yield-циклы с sleep(1000) без потери отзывчивости терминала.
Как только Вы вставите в любое место задержку на 1 секунду, цикл main встанет. Не важно где это будет - в самом main или в функции, корутине из этого main. И самое главное - зачем эта задержка аж целую секунду. Чтобы что?
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
nikolz написал:
OnOrder
Как это придет в терминал не детерминировано. Зато известно за что отвечает колбек OnOrder - за изменение информации о ордере. Информация записывается в таблицу ордеров и вызывается колбек. Я пока еще не видел сообщений от разработчиков о том, что колбек всегда приходит раннее информации о ордере в таблице ордеров. Допускаю что это приходит в одном информационном пакете. Как его разберет терминал тоже неизвестно.
Т.е. вероятно, что может прийти ранее. А может и нет.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Я не навязываю никаких решений. Боле того, не использую термин "фоновое", т.к. такого нет в Lua.

Задачи с ожиданием решаются через переключение. Как это делать - вопрос второй, хотите корутины - делайте. Дискуссия была про то, что корутины это не единственное, и уж те более не идеальное решение. Не более.

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

Если у Вас уже есть решение по обработки серверных данных, то и используйте его. Речь была про то, что это решение должно быть независимым от реализации алгоритма. Это просто набор методов, предоставляющий интерфейс. Соответственно скрипт должен просто дергать его методы, принимать решения по ответам.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Забудьте про слова асинхронность, потоки и т.д. Для начала необходимо зафиксировать все ситуации, которые могут привести к проблемам. А потому же решать вопросы про архитектуру. У Вас же все наоборот.

Представьте, что Вы в начале 90-ых, когда почти все писалось синхронно. Задачи же решались.

Цитата
Ожидание ответа в цикле main приводит к проблеме - зависанию
Потому что так делать нельзя. Любой блокирующий цикл - это зло.

OnTransReply - это колбек, ответ на отправку транзакции. Это не результат, а все лишь ответ. Он нужен чтобы прочитать ошибку отправки, чтобы не ждать ордер далее, т.к. он уже не появится. Все. В этом плане - это единственный колбек, который не вызывает вопросов.
Поэтому если отправили транзакцию на ордер, то результат - это не колбек OnTransReply, а появление записи по этому ордеру в таблице ордеров. Колбек же OnOrder - это уже следствие появления этой записи, а не наоборот. Любители обработки колбеков вынуждены решать вопросы с их приходом: гарантированность, последовательность, многократный приход, пропуск колбека за время простоя.
Т.е. если Вы решили их использовать, то сначала решите все эти вопросы на бумаге, потом уже в коде.

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

Задача сведется к подзадачам:

- Отправить транзакцию, с учетом лимита на число транзакций в секунду.

- Прочитать ответ транзакции. Найти ордер по транзакции. Это одна задача, т.к. ордер может появится раньше. Если ответ транзакции первый и там ошибка, то вернуться к пункту один или прекратить выполнение, в зависимости от алгоритма.

- Если это ордер с ожиданием сделок (рыночный), то если есть флаг исполнения ордера ожидать сделки по ордеру до исполнения количества. Но можно и не ждать, если алгоритм позволяет игнорировать это.

- Попутно проверять состояние ордера, т.к. он может быть снят и, возможно, его необходимо восстановить.

-- и т.д.

Т.о. выполнение задачи может быть долгим, но смысл разбиения в том, чтобы пока одна подзадача ждет результат (ждет не в блокирующем цикле), другая начала выполнение. И этот подход - это просто оптимизация. Как Вы это будете решать - дело ваше. Можете ждать колбек, может сами сканировать флаги, таблицы на новые записи.

Если вернуться к "Ожидание ответа в цикле main приводит к проблеме - зависанию", то решение - это по приходу колбека OnTransReply записать в некую таблицу результат по номеру транзакции. А уже подзадача проверки просто проверит в этой таблице на наличие записи. И сделает она это тогда, когда к этой подзадаче вернетесь, т.е. никакого ожидания с циклом. Тем более, что совершенно не понятно какое время ожидания указать. Много видел примеров с ожиданием 30 секунд. Всегда было интересно откуда эта цифра, а почему не 45? А если ордер пришел раньше ответа транзакции, то и проверка будет уже не особо нужна.

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

Т.о. рабочий скрипт будет 80% времени заниматься служебными задачами - контролем соединения; состоянием сессии; статусом торгов по инструменту; обслуживать интерфейс, если он есть; обновлять данные с сервера; проверять статусы ордеров, если не используются колбеки; проверять изменения позиции, баланса по деньгам и т.д. А так называемый алгоритм, который всего лишь автоматизирует торговые команды - это не самая большая часть скрипта. Поэтому складывается впечатление, что Вы начинаете не с того. Уж тем более не столь важно как технически реализован алгоритм, если скрипт не позволяет пользователю себя остановит и продолжить с того же места, не умеет останавливаться когда торговая сессия не идет и т.д.
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Цитата
VPM написал:
OnTransReply
OnTransReply может не вернуть номер ордера. Более того, он может прийти после первого OnOrder.

Так что он нужен только для проверки ошибка транзакции. Для получения номера ордера необходимо обращаться к таблице ордеров по номер транзакции.

С таймоутами тоже аккуратней, т.к. время ответа на транзакцию вполне может достигать минут. Все зависит от того, как работает сервер брокера. Отправили транзакцию, а ответы и записи в таблице ордеров появляются через 10 минут. Понятно, что это редкое явление, но достаточно одного такого случая, чтобы алгоритм наставил дублей ордеров, если нет проверок.

Ну и главное - колбек дело хорошее, но он не гарантирован.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 25 След.
Наверх