написал: Задача такая. Есть график или стакан по одной акции. Нужно запустить скрипт и он должен отправить заявку по этой акции. Для заявки нужен sec_code. sec_code должен браться автоматом от графика или стакана. Графики и стаканы привязаны якорем к таблице с акциями. Тоесть я постоянно выбираю бумагу, она всегда разная. Какую выбрал хочу нажать кнопку скрипта и по этой бумаге пошла заявка. все параметры заявок знаю с этим все ок. А вот sec_code чтоб брался это проблема.
Нет, так не выйдет. Точнее это можно сделать, если дополнительно сделать индикатор на этот график. При смене настроек на графике (изменение инструмента), простой индикатор определить через getDataSourceInfo какой в текущий момент инструмент и запишет эту информацию в какое-то хранилище (не важно какое, например метка на графике). Тогда скрипт прочитает это хранилище и получит информацию. Но надо решать вопрос синхронизации, т.к. смена инструмента не мгновенна.
Наверно, проще озвучить решаемую проблему. Но прежде надо определится, что и где используется - индикатор, скрипт. Для них используются совершенно разные походы.
Если Вы, действительно, хотите разобраться, то, наверно, все же стоит прочитать сообщения, что были написаны. А еще лучше документацию. В ней указаны все методы и, что важно, - сигнатуры вызова методов. Уже было сказано, что метод getDataSourceInfo вызывается без параметров. Этот метод доступен в контексте индикатора. Метод же getSecurityInfo - получает данные по переданным параметрам класс инструмента, код инструмента. Кои Вы и хотите узнать, а значит и использовать getSecurityInfo не получится.
И еще раз - по идентификатору графика можно узнать значения линий этого графика, а что это за график (и какого инструмента) нет.
getDataSourceInfo выдает информацию о графике, в котором он вызывается. Т.е. есть индикатор, нанесенный на график, в нем есть метод getDataSourceInfo. Вот по этому графику и будет информация. В руководстве показана сигнатура вызова:
TABLE info getDataSourceInfo()
Никаких параметров. Т.е. метод не предназначен для получения данных о другом графике по идентификатору. Такой вызов некорректен.
написал: Идентификатор назначен на Price. Тоесть именно на график. Хочу сделать сделку по этому графику. Для отправки ордера на сделку нужен sec_code. Как я могу его получить? Не задавать же его вручную. Знаю что можно из таблицы заявок вытащить local sec_code = last_order.sec_code. Должен же быть способ с графика открытого получить sec_code для заявки.
График предоставляет данные о линиях, выведенных на него. Раз это Price, то и будет выдана информация о барах этой цены. А чья эта цена метод getCandlesByIndex (если используется он) не предоставляет.
Читать данные с графика - это самый неудачный вариант получения данных. Его разумно использовать только если алгоритм вывода линий, на основании которых строится логика, неизвестен. В остальных случая проще и, главное, быстрее, надежней, получить данные через CreateDataSource (если используются дискретные свечи) и рассчитать алгоритмом некие значения. В этом случае вся информация известна изначально.
Нет, так сделать нельзя. Можно получить информацию только с того графика, на который этот индикатор выведен. В документации, файл "Интерпретатор языка Lua", раздел "Функции и глобальные переменные скрипта индикатора" описаны все доступные методы в индикаторе и список функций, доступных из контекста индикатора. Можно попробовать добавить метку на график с нужным текстом и считать данные. Но тогда графики должны быть уникальными.
nikolz написал: Посмотрите Выше мое сообщение от 29.12.2022 20:34:14 относительно Вашего теста. Он работает без проблем. Если что-то не так, то выложите скрипт для теста проверю еще раз.
Я уже все выложил. Даже видео работы записал. Разработчики его увидели. Зачем мне что-то еще доказывать для Вас. Вы говорите что нет проблем, у меня же тот же скрипт на чистом демо квике выдает обратное. Себе я верю больше. Тем более, что Вы видоизменили процесс вывода, убрав подсветку, убрав заполнение значения в ячейку, оставив только его представление. Если разработчики скажут, что у нас есть проблема с выводом числовых значений, то да.
Владимир написал: Alexander, Проблема В СКРИПТЕ! У всех данные прекрасно обновляются, а у Вас нет. Квик тот же, скрипты - разные. Точка.
Не у всех. Проблема в особенностях скрипта. Скрипт может быть корректным, но будет воспроизводиться проблема. Переписав скрипт по-другому, проблема уйдет. Но это не отменяет факт разного поведения в разных темах, различиях в поведении в зависимости от места вызова SetSell. Впрочем, с Вами спорить бесполезно. Тестовые скрипты уже были предоставлены, поддержка написала "Проблема изучается" и "Будет исправлена" https://forum.quik.ru/messages/forum10/message49120/topic3777/#message49120.
Я решил вопрос для светлой темы. Кто-то так и не смог из-за особенностей их скриптов.
Пять аргументов передается если тип колонки таблицы число.
Вы я приводил простейший пример, приводящий к замедлению обновления таблицы для светлой темы терминала. На темной теме тот же скрипт работает плавно. Уже давно добавил Highlite при выводе в светлой теме, т.к. ждать решения разработчиков долго. Ну и отказался от частых обновлений таблиц. Затратное это дело в терминале.
VPM написал: Посмотрел Вашу идею более внимательно. Не понял вот здесь "написать свой колбек на приход нового индекса" Вы говорите про исторические данные?
Да. Перебираем бары и когда надо перейти на новый индекс, вызывается функция. Также это будет работать и для текущих данных. Так что код становится однотипным.
VPM написал: Мало найти общую т. для входа нужен универсальный итератор.
Я ничего не говорю про точки входа, алгоритмы и т.д. Я говорил про написание своего итератора (https://www.lua.org/pil/7.1.html) , позволяющего писать что-то типа такого:
while ds_list:Next() do
При этом у каждого ds в списке можно написать свой колбек на приход нового индекса. Тогда код становится еще более простой, в функциональном стиле.
Владимир написал: Nikolay, Работает. Я написал небольшую утилиту, которая переводит исторические данные (тиковый массив) в секундные свечи - это и есть LAST, а "настоящие" свечи скрипт считает уже сам, раз в секунду опрашивая LAST из ТТТ, а в режиме работы по историческим данным получая его из очередной строки файла исторических данных. Там нет, конечно, BID/OFFER, но я их тупо приравниваю LAST. Вся остальная обработка одинакова для всех режимов.
Да, пока Вы это делали на том временном отрезке и только. А если это новый инструмент или данные 2008 года, то у Вас уже нет данных.
Владимир написал: Завязывайте вы с этим кретинизмом, господа, и считайте свечи сами - это в миллион раз проще, быстрее, надёжнее, чем ковыряться "в этом во всём". Я это сделал почти сразу после первого же знакомства с Квиком, и ни разу об этом не пожалел.
Вопрос был про исторические данные, на которых ваша методика уже не работает, т.к. никаких LAST нет год назад. Отдельный вопрос целесообразности этого, но он не имеет отношения к техническому решению.
Судя по всему Вы в алгоритме используете индекс, как факт прихода нового бара. А он увеличивается не по времени, а при совершении первой сделки в новом временном интервале. Поэтому новый бар может появится когда угодно, может даже не прийти вовсе, если сделок не будет.
Закрытие же бара - это цена последней сделки в временном интервале бара из таблицы обезличенных сделок. Можете отслеживать время сделки из ТОС, можете просто, при факте наступления нового интервала, принимать, что бар закрылся. Т.е. надо переходить на контроль времени, а не появления нового индекса бара.
Я не использую данные с графиков, только потоки данных и расчет на них. Да и спрятать можно все, написав свой итератор. Тогда вызов станет универсальным, простым в конечной точке вызова.
Алгоритм синхронизация разных ТФ достаточно прост. Синхронизация идет по времени бара, т.к. время это общее что связывает ТФ. Надо определить наименьший ТФ. Далее есть точка отсчета как отметка времени. Необходимо установить младший ТФ и все старшие на эту начальную точку, т.е. найти тот индекс в каждом ТФ, который соответствует этой отметке.
Теперь необходим итератор по индексам младшего ТФ, от начальной точки.
Переходим на следующий индекс. Проверяем старшие ТФ: новая отметка времени требует увеличения индекса старшего ТФ? Если да, то увеличить.
Таким образом, на каждой итерации текущий индекс каждого ТФ будет соответствовать текущему времени итерирования.
Для примера ТФ 1 мин, 5 минут.
Стартуем от 10:00.
Увеличиваем индекс ТФ1 на 1. Это будет 10:01. Для ТФ 5 минут все еще длится бар 10:00. Значит по нему увеличения индекса нет. Так доходим до 10:05. В этот момент для ТФ 5 минут выполнится условие нового бара. Значит по нему увеличиваем индекс на 1.
Игорь М написал: Причем здесь какой-то мой алгоритм? Подняли тему и я написал,что TRADINGSTATUS криво работал раньше, написал что проверю снова. Вот проверил, ничего не поменялось. Написал сюда, чтобы люди, которые будут потом читать, не тестировали заново. Резюмируя: TRADINGSTATUS - бесполезная мура, 10-15 секунд это перебор для любых систем. За эксклюзивную информацию о том, что "система торговли Квик - это не тот инструмент, что стоит использовать" для "мгновенной реакции", низкий поклон, конечно. ::
Вы же говорите, что задержка в 15 секунд для Вас критическая. Я пока не видел с этим проблем, для любых торговых систем. Совершенно разные мнения.
Игорь М написал: Для информации: проверил снова за эти два дня, как были раньше неадекватные задержки, так и остались. Значения писались в лог при их изменении (SiU3): 140514.690: status: 1
Вчера статус на 11-ой секунде после возобновления торгов поменялся, а сегодня на 15-й.
Если Ваш алгоритм требует мгновенной реакции, то, видимо, стоит задуматься, что система торговли Квик - это не тот инструмент, что стоит использовать. Хотя, конечно, можно дополнить получение статуса косвенными методами. Получите статус по тому, какой сработает быстрее.
nikolz написал: Определяете, что торги идут в принципе (был такой магазин ) Потом проверяете объем торгов по данному инструменту. Если ноль, то не торгуется. Можете еще проверять наличие предложений. Если инструмент не торгуется то и предложений нет
Все косвенные методы не отвечают на вопрос о статусе торгов конкретного инструмента. То что торгуется Сбербанк, не значит что торгуется фьючерс. То что торгуется один инструмент, не значит, что по другому нет стоп торгов. А по третьему планка и остановка торгов. Так что если вопрос: узнать состояние торговой сессии по конкретному инструменту, то этот статус транслируется. Все остальные методы косвенные, и не факт, что задержка будет не больше.
Игорь М написал: По поводу TRADINGSTATUS: Я когда-то тестировал его и, если не ошибаюсь, он криво работал. Он в 14:05:10 показывал 0, хотя торги уже 10 секунд шли, и лишь на 11-ой секунде он стал 1. Такая же история и с вечерней сессией. Надо в понедельник проверить снова.
Возможно. Но другого способа достоверно узнать, что сессия открыта, нет. Хотя, конечно, можно использовать косвенные способы, например - отправить транзакцию и посмотреть ответ. Но это просто пример экстремального способа. Что касается изменения цены, то это, конечно, не даст ответ о состоянии сессии по инструменту, а просто покажет активность участников.
18.08.2032 торги на срочном рынке FORTS после проведения дневной клиринговой сессии возобновились в 14:27:00.
Известен ли кому-нибудь способ получать информацию о "необычных" временах начала/возобновления торгов? Насколько я понял, доступа к таблице системных сообщений нет. Здесь предлагают использовать поле TRADINGSTATUS ответа getParamEx, но, судя по обсуждению, не до конца ясно, можно ли на него полагаться.
Есть ли другие варианты, в т.ч. костыльные?
Благодарю за ваши предложения.
Да, именно этот параметр даст состояние сессии. И он вполне корректно отработал в этот день, как в другие дни, когда статус торговой сессии по там или иным причинам по инструменту изменяется.
Сергей С. написал: Да, это реальный торговый счет. Сначала этот вопрос я адресовал брокеру. На что он сказал, что это проблемы на стороне клиента Квик. Брокер ФИНАМ. У других брокеров есть такая особенность первой сделки?
Клиент Квик не может приводить к задержкам, т.к. он клиент. Его задача просто получать данные с сервера брокера. Правда проверьте, что у Вас просто не установлен период получения данных. Иногда ставят период 10 секунд который задан по умолчанию, что и приведет к таким задержкам.
Проверить же можете просто. Пишите скрипт, фиксирующий в логе, сообщениях (не важно) время отправки транзакции, время прихода колбека о ордере, сделках и, главное, время прихода колбеков OnDepoLimit или OnFuturesClientHolding. Сразу будет видно как сколько времени тратится на полный цикл.
Свою позицию Вы знаете. Размер лота и цену последней сделки получите из потока данных (условно Таблицы текущих торгов) через метод getParamEx. В документации все методы qlua описаны.
VPM написал: Что то я совсем не могу понять, что средствами qlua нельзя получить стоимость контракта на fut?
Вы про какую стоимость спрашиваете? Про размер ГО, уплаченный по сделке или стоимость в в валюте цены? Если про ГО, то это величина, рассчитываемая по формуле, зависящей от многих параметрах, спецификации контракта. На этом форуме уже обсуждалось и приводился пример такого метода.
Это Вы про реальный торговый счет спрашиваете? На демо счете ARQA это такая особенность. На реальных счетах разных брокеров особой задержки не наблюдал. Впрочем, от брокера зависит, конечно.
Этот код - это просто демонстрация работы с ордерами как объектами через колбеки и обработка их через корутины. Также есть получение данных ТТТ и данных с графиков. Все. Сказать что это код для работы можно с очень большой натяжкой. Элементарно - выключил скрипт, все данные потерял. Надо дописывать хранение данных между запусками. Также пропустил колбек - ордер не будет в актуальном состоянии. Ну и другие вещи - обрывы связи, ожидание получения данных, смена торговой сессии, суток, ошибки чтения данных с графиков и т.д.
Так что как модель, пример - ок. Но оставлять его без присмотра - это надо быть смелым.
У нас так мало инструментов, что самое простое - это сделать файл с данными и просто прочитать его при старте. Лучше даже сделать его в формате таблицы, чтобы загружать одной командой loadfile.
Хоть разработчики и декларируют, что доступно описание полей на русском, но все же стоит описывать транзакцию через поля, описанные в документации в английской нотации. И только те поля, что не имеют английской нотации на русском, полученные через сохранение формата транзакций из кармана транзакций. Правда придется такой квест проделать, чтобы выявить такие поля.
Впрочем, видимо, не нравится поле Класс. В пишется код класса, а не имя.
А чем же разработка Дениса Колодина плоха, можно смотреть можно запускать запускайте. Я доделал версию с ним пока простенькую, хочу погонять, версию поднял до 5.4. На мой взгляд если глюки серьезные не вылезут Вооооще шик!
Кто-то говорит о качестве разработки. Я ее видел уже не помню когда, лет 7 назад, наверно, если не больше. Хотите обсудить технические решения, ограничения, недостатки этого кода - это одно, но Вы же обсуждаете совсем другое.
VPM написал: Ну смотрите 3 кода предлагал обсудить, и где кто?
Обсуждать что? Идеи торговли - не интересно. Алгоритмические проблемы, решение проблем разработки - да. А обсуждать "на скамейке" проблемы марсиан, не видя их ни разу - такое...
Наверно, имеет смысл перенести обсуждение на другую площадку - Smart-Lab, MFD. Вы там найдете много участников по столь животрепещущей теме. Здесь, все же, форум по разработке, коду. Поиск Граалей - это о другом.
Советую Вам придерживаться правила, что если пытаетесь думать как крупный игрок, то им и надо быть. Иначе все это - "если бы я был, то". Проблема в том, что когда ты являешься, а не если, то с удивлением обнаруживается, что задачи совсем разные. И чтобы понять, надо быть или хотя бы поработать год в подразделении инвестиционного учреждения (не в отделе охраны). Можете просто даже воспользоваться поиском по научным работам в области финтеха. Правда здесь сразу надо оговориться, что искать надо не в российской части сети. Интересно видеть, как то, чем занимались в мире финансов с 00-х, когда мощности уже позволяли, постепенно приходит в обыденную жизнь.
Впрочем, это правило применимо и для любой области знаний. Хотя теперь у нас все сами себе режиссеры.
Просто к слову: у рынка нет таких свойств как перекупленность и перепроданность. Ну и волатильность - это более сложное понятие.
VPM написал: Господа, ругается VM Lua ошибка следующая ACCESS_VIOLATION Чем может быть вызвана, я полагаю нужно sleep увеличить?
Возможно lua 5.3. На версиях терминала 8.*, под lua5.3 вылетала часто. Хотя это может быть и ошибка работы с объектами, нарушения синхронизации доступа в потоках.
Снимают перед большой игрой! Увеличивая тем самым ликвидность рынка + доп. импульс. Здесь не нужны мнения Гуру достаточно рынок почитать.
Да, у них работа такая - снимать стопы. Это просто движение цены, как нестационарный стохастический временной ряд. То что в какой-то момент времени волатильность отклонилась от исторической, как бы не хотели этого "инвесторы", не означает что это злой умысел. Это всего лишь такова реальность в тот момент времени.
А пример с нефтью теперь приводят на каждом углу. На да, биржа нарушила спецификацию контракта, и что. Не она же сделала цены отрицательными. Хотя любой, кто собирается торговать товарные рынки должен понимать, что иногда товар может стать не активом, а пассивом.
Если бы такие временные ряды было легко спрогнозировать, то, наверно, это уже давно бы сделали. Но нет, упорно натягиваем простейшие фильтры на ряд и "видим" будущее. И, возможно, ближайшее и можно увидеть, особенно на истории. Хотя есть текущий момент времени, есть участники, их желания и совершенные действия сейчас, не вчера. Вчера они продавали, сегодня покупают. Вот так сложилось. А RSI все это подтвердит - работает же...
VPM написал: Ну это тоже из области сказочки! :: Как он может быть случайным если управляется Маркетмейкерами которые держат позиции с двух сторон и видят на доске ордера всех участников. Тому хороший пример недавними события с нефтью нужно было у ти от убытков загнали цену в минус.
Советую избавиться от иллюзий и мифов по ММ, Кукл и др. персонажам. Впрочем, это, видимо, будет вечно. Это же так удобно, когда есть всемогущие персонажи. Виноваты же они, а не система. Стопы они снимают, защиты нет. Уже давно были проведены количественные эксперименты по случайным методикам входа в позицию. Элементарно монеткой, кубиком. Все сводится к управлению рисками. Впрочем, тем, кто не гадает, а изучает компании в которые собирается инвестировать, монетка не нужна, как и скользящие средние и т.д.
x={one=4, next="a"} y="" for key in paris(x) do y=y.." " end message(y)
Если задача склеить их в строку и если их очень много, то лучше это делать через промежуточную таблицу, записав в нее ключи. А потом вызвать table.concat
По смыслу - простая система. По реализации - очень сложная. Лучше всего торговать сеткой инструменты или синтетические конструкции, которые находятся в "вечном" боковике - спреды. Есть даже готовый инструмент на бирже - календарный спред.
Да я с этим замучился, в программировании у меня базовые знания инженера мой первый персональный "ЕС 1841" сов. разработка. и работы я свои не пишу, а скорее собираю как "конструктор" находя интересные вещи в том числе и Ваши. Но если движок худой то остальным и заниматься бессмысленно. Вот и вспомнил старые работы.
Ну мой первый терминал 1842... У меня выложено много, т.к. я тоже знакомился с qlua в терминале. И когда я начинал было мало информации. Т.к. особой ценности все это не несет, то и скрывать нечего. Много кривого кода - тоже думал "все просто же". А потом разные брокеры заставили усвоить, что все не так очевидно. И первое что было "выкинуто" - это колбеки.
А этот пакет я, конечно, видел. Но с ним можно сделать достаточно небольшое число алгоритмов. Если не считать того, что он берет данные с графиков, что тоже надо сразу переделывать. Также он совсем не учитывает торговое время, обрывы связи, долгие ожидания ответов на запросы к серверу и т.д. Т.е. это просто некий пример-модель работы.
Согласен полно, но если он позволит мне заниматься торговлей а не шарить по движкам получая очередные оплеухи, я ему все прощу.
Здесь проблема в том, что достаточно одного сбоя, чтобы привести к существенным потерям, многократно перекрывающим все прошлые успехи. Собственно все это обсуждение об этом, на самом деле. Я придерживаюсь принципа, что если есть шанс получить критическую проблему даже 0.1%, то значит этим надо заниматься. Это как в авионике, софте медицинского оборудования - нет места для проблем. Поэтому и выбираются подходы, может не самые красивые, удобные, модные, но снижающие риски.
Вы можете его использовать как пример, правда если понимаете используемые концепции. Сказать, что его можно отпускать в работу на реальном счете - наверно нет. Слишком много нюансов при реальной работе через брокера.