Cubigator, тут важно оценивать результат такого исполнения. Лимитные заявки — это хорошо, но цена может начать двигаться импульсно, так что лимитка (вы ее вероятно будете переставлять вслед за ценой) долго не исполнится. Окупит ли тогда выгоды на комиссиях потери за счет входа по более худшей цене.

Cubigator, ну ничего удивительного… К этому все приходят. Торговля по тренду самый простой и надежный подход. Долгосрочно люди не хотят торговать, а краткосрочно всего несколько инструментов, которые пройдут по торговым затратам…

Cubigator, торговля по тренду на внутридневных ТФ, самые ликвидные и дешевые фьючерсы с минимальными комиссиями и проскальзыванием…

Cubigator, все три подхода:

— ручной для медленной инвестиционной стратегии (таблица и ручное исполнение);

— полуавтомат для среднесрочной стратегии (расчет в python -> выгрузка в csv -> исполнение на Lua);

— полный автомат для быстрых стратегий (расчет и исполнение на Lua).

Cubigator, а что делать? если желающих всегда хоть отбавляй;)

Cubigator, понимаю, мотивация — важная вещь

Cubigator, а вы пробовали подход с подпиской Subscribe_Level_II_Quotes? ИИ рекомендует так:

function main()
local class_code = «TQBR»
local sec_code = «SBER»

— Подписываемся на стакан для инструмента
Subscribe_Level_II_Quotes(class_code, sec_code)

message(«Подписка на стакан активирована для »… sec_code)

— Скрипт работает, ожидая обновления данных по стакану
while true do
sleep(1000) — Ожидаем
end

— Отписка (в реальной работе нужно сделать отписку перед завершением скрипта)
— Unsubscribe_Level_II_Quotes(class_code, sec_code)
end

function OnQuote(class_code, sec_code)
— Функция вызывается при каждом изменении в стакане
local order_book = getQuoteLevel2(class_code, sec_code)
if order_book then
— Обработка данных по стакану, например, вывод данных о лучшей заявке на покупку и продажу
message(«Bid Price: »… order_book.bid[1].price… ", Offer Price: "… order_book.offer[1].price)
end
end

Долбаёб у меня нет квика поэтому я могу только предполагать из за чего у тебя фуфела не работает. Я предположил а ты пишешь сумашедший/дебил. Попробуй так candles = getCandles(«SEC», 0, 100) для свечей. Для стакана если тебе не нравятся ответы чатгпт то вот здесь есть ответ как без ГУЯ получить стакан. --> «quik2dde.ru/viewtopic.php?id=419»
цитата:

Кто-то спрашивает:

Мне нужно получить стакан без открытия стакана в Квике.

Я так понял это три основные функции:

-OnQuote
-getQuoteLevel2
-Subscribe_Level_II_Quotes
...

Кто-то отвечает:

Subscribe_Level_II_Quotes как раз и требуется для того, чтобы получить стакан с помощью getQuoteLevel2 без открытия таблицы стакана.

— пример
— задаем класс инструмента и инструмент
CLASS=«TQBR»
SEC=«SBER»

— один раз подписываемся на стакан
if Subscribe_Level_II_Quotes(CLASS, SEC) then
message(«Quotes Subscribed», 1 )
else
message(«Quotes NOT Subscribed», 2)
end

— после подписки получаем стакан столько раз, сколько нужно
qt = getQuoteLevel2(CLASS, SEC)

— отписываемся от получения стакана
Unsubscribe_Level_II_Quotes(CLASS, SEC)

Поэтому вытащи говно из своей башки, прочитай почему не надо брать данные с ГУЯ(можешь в интернете полазить), но судя по всему у таких олигофренов как ты элементарные вещи даже в голове не помещаются из за того что там вместо мозга говно. Мне вот интересно почему всякие выблядки вроде тебя начинают писать дебил и т.п. я же тебе такого не писал первый, зачем грубить Вась?

вот ещё чатгпт накидал несколько причин для тебя дятла:

• Ненадежность: GUI — это визуальное представление данных, а не их источник. Данные в GUI могут быть:
  • Округлены или отображены с ограниченной точностью.
  • Фильтрованы или отображены частично, чтобы сделать их более удобными для просмотра.
  • Изменены пользователем (например, масштаб графика, выбор отображаемых элементов).
  • Изменены программно (например, изменения в представлении данных, переключение между режимами).
• Нестабильность: GUI — динамическая среда. Элементы GUI могут быть изменены пользователем или программно:
  • Пользователь может перетаскивать элементы, изменять их размер или скрывать/отображать.
  • Программа может автоматически изменять GUI (например, отрисовывать новые элементы, перестраивать структуру GUI).
• Сложность: Доступ к данным в GUI часто требует сложных манипуляций:
  • Необходимо использовать специальные функции для извлечения текстовых значений из GUI.
  • Необходимо учитывать динамичность GUI и программно отслеживать изменения в элементах GUI.
• Отсутствие гарантий: Нет гарантии, что данные, полученные с GUI, будут точными, современными или полными.
• Плохая практика: Чтение данных из GUI делает код:
  • Сложным, менее стабильным, менее читаемым и менее переносимым.
  • Менее устойчивым к изменениям в GUI.
  • Более сложным в обслуживании и отладке.

Лучшие практики:

• Получать данные из источника: Если данные доступны через API, базу данных или файлы, используйте эти источники вместо GUI.
• Использовать события: Если нужно отслеживать изменения в GUI, используйте события (например, события изменения текстового поля, события изменения масштаба графика).
• Разделять логику и представление: Старайтесь разделять логику программы и представление GUI. Это позволит упростить код и сделать его более переносимым.

Как я и писал до этого возможно что твоя проблема

… Там есть проблема именно на первой свечке ПОСЛЕ клиринга, данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика. И это тоже нужно учитывать...

связана что используешь квик/луа через жопу. Но понять это такому упоротому как ты это наверное не дано.

П.С.
чтобы рассуждать на тему дебилизма тебе следовало бы для начала почистить ту дичь которую ты постишь и уже потом смотреть в это направление.



Долбаёб.)

Cubigator, 

… Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

чатгпт говорит что так можно получать без ГУЯ(проверить не могу т.к. у меня линукс, квик 5000 лет не пользовал, луа никогда вообще и т.д.):

— Задаем класс инструмента и инструмент
CLASS = «TQBR»
SEC = «SBER»

— Подписываемся на стакан
if Subscribe_Level_II_Quotes(CLASS, SEC) then
message(«Quotes Subscribed», 1)
end

— Получаем стакан
local qt = getQuoteLevel2(CLASS, SEC)

— Выводим информацию о стакане
if qt ~= nil then
print(«Ask:», qt.offer[1].price)
print(«Bid:», qt.bid[1].price)
end

— Получаем свечи
local candles = getCandlesByIndex(SEC, 0, 100) — Получаем данные о 100 первых свечах

— Выводим информацию о свечах
for i, candle in ipairs(candles) do
print(candle.time, candle.open, candle.high, candle.low, candle.close)
end

— Отписываемся от получения стакана
Unsubscribe_Level_II_Quotes(CLASS, SEC)

Возможно Ваша проблема возникает из-за Вашего говнокода:

… Там есть проблема именно на первой свечке ПОСЛЕ клиринга, данные какое-то время считать нельзя, и еще после клиринга иногда меняется количество свечек в графике, а это мега-критично, так как из-за пропущенных свечей может поменяться вся логика. И это тоже нужно учитывать...

Попробуйте вместо:
getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1)

использовать:
getCandlesByIndex(SEC, 0, 100)

Не удивлюсь если проблема возникает из-за того что Вы вместо обращения к бэкэнду обращаетесь к ГУЮ(указывая ID_Graph). ГУЙ обновляется асинхронно но асинхронность != консистентность(lanes/атомарные структуры данных/shared memory/volatile). В бэкэнде свечи должны быть на месте(с чем в ГУЕ могут возникать проблемы из-за потоков, частоты обновления ГУЯ, ядро легло спать не воткнув данные в ГУЙ а воткнёт когда встанет и т.п.). Поэтому когда Вы пишете на форуме и думаете что общаетесь с разработчиками, на самом деле Вы общаетесь с техподдержкой(в которой могут за небольшие деньги работать такие же кубигаторы как Вы) и уже от техподдержки летит весь шквал г@вна который говнокодеры сами и создают а потом пишут в квик что он тормозит и не все свечи выводит. Делайте с учётом таких моментов как «лучшие практики» и очень большой пласт потенциальных проблем просто не возникнет т.к. Вы с ним даже не будете соприкосаться. Пример одного из пунктов «лучших практик» не брать данные с ГУЯ, вместо ГУЯ брать с бэкэнда. Даже не понимая почему так а не иначе можно избежать множества потенциальных проблем. Для примера что за проблемы могут быть: бид аск очень часто у бота и в ГУЕ разный(чем активнее инструмент тем чаще это будет проявляться) это может проявляться даже если Вы данные берёте из бэкэнда но у Вас разные потоки(для этого придумано lanes/атомарные структуры данных/shared memory/volatile). Часто любители потоков удивляются почему у них стаканы кривые, одна из причин может быть то что я описал.

Cubigator, 
Ну да, в чем проблема купить на ямочках, продать на горочках?

Cubigator, 

… Проблема отсутствия данных после клиринга, о которой вы говорите...

Проблема с внимательностью у Вас(я не писал ПОСЛЕ клиринга я писал ПОСЛЕ ЕГО НАЧАЛА), внимательно читайте что я писал и вдумывайтесь в то что написано:

Совет: проведите такой тест — включите квик и Ваших ботов, дождитесь клиринга и убедитесь что !!!--> ПОСЛЕ ЕГО НАЧАЛА <--!!! (дальше тоже внимательно)--> Вам не приходят данные(которые только добрались до Вас т.к. бот был сильно занят расчётами и тасканием данных с графиков). smart-lab.ru/blog/1076580.php#comment17454415

… Какой идиот будет, что-то считывать во время когда идет клиринг? Робот в это время на паузе...

Если в бота приходят данные и он не успевает их обрабатывать то будет копиться очередь, у меня приходили данные 3 минуты после начала клиринга, поэтому никто их не считывает они не успевают вовремя обработаться поэтому копятся. Именно это я написал Вам проверить но с внимательностью у Вас проблемы, поэтому так подробно расписал.

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

Так может это из-за того что надо их брать не с графика а из бэкэнда? Не думали об этом?

… Я так понимаю вы вообще великий теоретик, но с практикой беда. Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

Насчёт луа, да никогда не использовал. Спросил у чатгпт, он сказал что можно:

ChatGPT:
Убедитесь, что у вас есть права доступа к данным уровня 2 и что нужный инструмент выбран правильно. Также проверьте настройки вашего терминала, чтобы разрешить доступ к данным стакана без графика.

Я:
то есть для этого не нужен график?

ChatGPT:
Да, для получения данных стакана с помощью функции getQuoteLevel2 график не требуется. Вы можете вызывать эту функцию в своем скрипте без необходимости открывать график. Главное — убедиться, что у вас есть доступ к данным уровня 2 для выбранного инструмента.

так же Вам писал коллега:

… график не обязательно открывать, если создать источник данных из Луа. Он эквивалентно делает подписку на сервер. smart-lab.ru/blog/1076580.php#comment17454189

Именно так и должны использоваться данные а не те костыли которые(с большой долей вероятности) используете Вы. Возможно те проблемы о которых Вы пишете что типа разработчики не делают как надо и самому приходится… Возникают именно из-за того что Вы используете квик/луа через жо#у и Вам видимо все эти костыли по кайфу. Поэтому чтобы понимать как нужно работать с данными в квике не надо знать луа и т.п. надо просто понимать как с данными не принято работать и этого достаточно чтобы не городить говнокод и потом за#бывать разработчиков тупыми вопросами на форуме. Соревнуясь между собой у кого какая тема ляжет светлая или тёмная или любая какую не дай.

Ещё есть момент с путаницей в показаниях:

Gambler <osaengine.ru>:
… график не обязательно открывать, если создать источник данных из Луа. Он эквивалентно делает подписку на сервер.

Вы:
… Я знаю, но так проще, а значит стабильнее...

И мне пишете:
… Попробуйте выполнить getCandlesByIndex без открытого графика или getQuoteLevel2(class_code, sec_code) без открытого в Quik стакана, тогда поймете что откуда берется...

А как же:
… Я знаю, но так проще, а значит стабильнее...

Значит не знали когда писали?(я кстати об этом писал выше smart-lab.ru/blog/1076580.php#comment17454332)

… Особенно было смешно читать ваши рассуждения про черную тему в Quik.  Поверьте людям она намертво кладет Quik это проверенный факт.

Почитал форум там пишут что и светлая кладёт квик. Поэтому там скорее всего писатели кода так его пишут что в «какой цвет не покрась они её всё равно положат».))) Поэтому ситуация не очевида. Откуда разработчики квика знают что именно кладёт квик? Может там такие «ядрёные велосипедные связки, многопоточность и т.п.» что хорошо что квик тормозит а не взрывается.

Cubigator, 

… И вот как раз этот извращенный до нельзя способ и подтвердит их неадекватность. А сделать это нормальным способом, о котором их годами просят пользователи они неспособны. Ваше пожелание зарегестрировано — идите на юг.

Я их понимаю т.к. пишу всё сам. Но мне намного легче т.к. у меня «кастомный кейс» а у них все рынки, все инструменты, биржа сделала новую фишку все сразу пишут квик где нам новая фишка и т.д. Я как-то хотел по криптовалюте посмотреть но там есть некоторое кол-во отличий которое меня «не вдохновило». Например одна из причин — числа с плавающей точкой, я их никогда не использовал т.к. всегда только фьючерсы и всегда(почти) только си а там даже объёмы с плавающей точкой. У меня заточено всё под микро(использовать мало памяти, ссылки/указатели чтобы влазить в L1 и т.п.) т.е. пришлось бы кое-что переписывать и я не стал заморачиваться. А у них так нельзя всё расписано по дням и всё такое.

… Иначе после аварийного перезапуска системы в Quik ни один нужный скрипт не запустится...

Так docker/docker-compose же есть. Пропишите и всё, там можете определить что после чего запускать, сколько ждать, сколько раз перезапускать, что проверять запущено или нет и всё такое.

Cubigator, 

… Проблема отсутствия данных после клиринга...

Это не проблема. Это то как должно быть. В клиринг данные не должны приходить т.к. клиринг идёт. Если бы они продолжали приходить то это бы означало что где-то происходит «неуспев» и нужно искать где и почему. Но если у Вас такого нет то значит всё ок.(у меня по молодости было 14:03 а данные всё идут это как бы намекало что когда торговал то не совсем в тех данных ставил ордера и неудивительно почему бот работает не так как хотелось бы, у меня была связка эксель + квик, поэтому ГУЙ и данные лучше разделять(т.е. брать из бэкэнда а на ГУЙ можно смотреть можно не смотреть это уже дело вкуса)).

… Даже автоматические перезагрузки сервера во время обновления системы или аварийные ситуации провайдера VDS которые иногда случаются, никак не могут остановить работу скрипта. Он все равно запустится, и даже если были пропущены некоторые действия скрипт самостоятельно все восстановит. Я иногда месяцами не трогаю ничего...

Ну это уже больше девопсовские штуки и они сильно не критичны. Их можно делать 100500 разными способами например докерами и т.п. Это всё не относится к «горячему пути» а вот брать данные с ГУЯ, лучше так не делать. Но Вы скорее всего так и не делаете т.к. getCandlesByIndex(ID_Graph, 0, x-MaxPer-2, MaxPer+1) с ГУЯ данные(скорее всего) не берёт он их берёт из бэкэнда луа именно из этого же места они отдаются ГУЮ какой-то где-то метод(в коде квика(не луа)) их забирает и отдаёт на отрисовку.

Cubigator, 

За полтора года получения данных из графиков не было ни одного сбоя.

Даже сама фраза звучит как мем.)

Совет: проведите такой тест — включите квик и Ваших ботов, дождитесь клиринга и убедитесь что после его начала Вам не приходят данные(которые только добрались до Вас т.к. бот был сильно занят расчётами и тасканием данных с графиков).

Cubigator, 

 … Я знаю, но так проще, а значит стабильнее.

 А потом появляются коментарии типа почему квик висит. Потому что:

 … так проще, а значит стабильнее.

)))

 … Я знаю

 Очень сомнительно.

За полтора года получения данных из графиков не было ни одного сбоя.

Опишите в общих чертах как Вы это тестировали чтобы так говорить.)))

Cubigator, 

… но если не знаете не утверждайте.

 Я знаю что данные берутся с бэкэнда и только не совесм умные люди берут их с фронтэнда.

 Про адекватность коллег из Квика, зайдите на форум Квика, вам там расскажут про их «адекватность».

Кто расскажет? Такие же кубигаторы как Вы?))) Мне их и здесь достаточно. И объяснять им очень сложная и затратная задача, которая держится только на «тщеславных моментах».

Cubigator, график не обязательно открывать, если создать источник данных из Луа. Он эквивалентно делает подписку на сервер.

Cubigator, писал ранее про создание алгоритма через GPT smart-lab.ru/blog/1037920.php С тех пор ИИ только поумнел )

А так, мой сайт со сборником всех популярных опен сорсов osaengine.ru/ Если уж и программировать, то через какую-то платформу.

Cubigator, 

… даные считываются из открытого в Quik графика...

Сомневаюсь что с графика т.к. квик делали адекватные коллеги которые понимают что ГУЙ нужен для отображения данных а не для того чтобы их оттуда брать(ГУЙ всегда работает в отдельном потоке поэтому данные будут разными постоянно в общем точно не с графика поверьте). Данные берутся всегда из бэкэнда и только у изобретателей велосипедов с ГУЯ. Изобретение таких «корявых» решений может приводить к тому что данные которые дожны тестироваться за 5-6 секунд тестируются 2 минуты 23 секунды как в этой теме — Торговая стратегия «все сделки в плюс» бесплатно --> «smart-lab.ru/blog/1075769.php». Если нужны детали почему 2 с лишним минуты для тестирования слишком «рукалицо» с удовольствием распишу подробней.(это я взял самый затратный вариант — тики, а если там 6 лет тестировалось на свечах то «рукалицо²»). На свечах даже если минутных 6-10-15 лет должны тестироваться 0 секунд.

Вспомнил отрывок из варкрафта:

— не понимаю как Вы люди выживаете, никаких мышц, хрупкие кости.
— ты не сильно от нас отличаешься.
— как же ты выжила?
— ломаные кости потом крепче.
— мои очень крепкие.

Cubigator, я немного не о том. Ну, да, ладно.