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

И сразу возникает вопрос: как будут работать методы, где есть входной параметр limit_kind?

Сообщение в терминале увидел. Вот оно, чтобы было понятно остальным:

Здравствуйте.С 16 января сервер QUIK Junior переведен на современную схему ведения позиций - по календарным датам. Если ранее каждой позиции соответствовал код расчетов (T0, T1, T2), то теперь - конкретная дата.
Например, если сегодня 16.01.2025, значит код расчета T0 соответствует дате расчета 16.01.2025, код T1 - 17.01.2025 и так далее. Ожидается, что в будущем на эту схему перейдет большинство брокерских компаний. Кроме того, теперь расчеты по всем инструментам на сервере происходят по схеме T+1, что соответствует режиму реальных торгов на Московской Бирже.
В связи с этим в таблицах с позициями по инструментам и деньгам следует заменить параметр "Срок расчетов" на "Дата расчетов". В таблице "Состояние счета" вместо кодов расчета теперь подставляется конкретная дата.


Правда это, конечно, несколько неожиданно, не говоря уже о каких-то формальных документах. Спрашивается а как теперь для инструментов, торгуемых в разных режимах определять позицию. До этого можно было найти максимальный limit_kind и по нему фильтровать записи. И он не изменялся. Теперь же схема работы становится печальной - каждый день этот параметр будет изменяться, т.е. необходимо заново его обновлять, и это если брокеры не придумают чего-то еще. На сайте биржи да и в транслируемых данных есть показатель режима торгов для инструмента. Никаких расчётных величин нет. Зачем это, какую проблему решает это нововведение? Представляю, что ждет работающие скрипты при переходе брокеров на этот режим.

Сегодня на тестовом контуре в таблице depo_limit получил такое:

limit_kind = 20250116

Это что? Ясно что дата. Но с какой такой... Я не слышал о новом режиме торгов в виде даты. Есть Т0, Т+1, Т+2, TOD, TOM и новое Т365, отображаемое в терминале Тх.

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

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

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

Не видел таких проблем для единого счёта. Вы бы вывели поля каждого счёта, да посмотрели что у него в поле классов.

Пишите сервере на lua, открываете наружу порт и пожалуйста. Правда смелость этого решения высока.

В папке socket должны быть еще файлы lua, реализующие протоколы.

Ищите библиотеку socket. Она поддерживает http. Безопасное соединение не поддерживает, для этого необходимы дополнительные библиотеки, в частности luasec.

Справедливости ради - это не среда Linux. Вот если бы терминал был нативный для Linux - это было бы прекрасно.

Проще сделать автосинхронизацию каталогов. Изменяя базовый, остальные зеркалируются.

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

А причём здесь Квик? Где изменение данных в переменой localtime. Оно как осталось от инициализации так и не изменяется.

Как пользователь MacOS уже более 15 лет был бы раз видеть это. Но так уж сложилось в мире финансов - основные профессиональные инструменты на Windows. И это не только здесь, но и по всему миру так.
Это положение изменяется  постепенно, но не в ту сторону как хотелось бы. Теперь все делается на серверах Linux как backend, а интерфейс рисуют через Web приложение, что ужасно. Это пусть для масс. Проф. участники продолжают использовать свои решения и Mac там представлен минимально.

Так что не ждите, особенно сейчас, когда доля устройств на пространстве Quik Mac мизерна. Linux даже больше. Вот для него дистрибутив не мешало бы делать, во избежание казуса, если все перестанет работать.

Тестовый контур Quik Junior 11.3.2.2

Ответ транзакции:
[INFO  2024-09-18 13:13:09] : OnTransReply all trans count: 8 | sec_code SiZ4 result_msg: Ответ из торговой системы не получен, статус исполнения транзакции неизвестен. За уточнением просьба обратиться к Вашему брокеру. status: 4 trans_id: 50553350 order_num: 0 price: 80013 qty: nil account SPBFUT000i4 client_code SPBFUT000i4 firmid nil brokerref SPBFUT000i4//NTR01


Не то чтобы нужен ответ, но просто хотелось бы понять причину. Это что-то новое: запрос сделан, ответ - кто же знает что там случилось.

Плюс, возможно, еще нужен НКД - это параметр ACCRUEDINT

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

текущая цена - LAST
номинал - SEC_FACE_VALUE

сответственно стоимость - это цена*номинал/100


класс не информационный, а торгуемый. Его можно узнать на сайте бирже или прямо в терминале в таблице текущих торгов.

Стоимость лота - это стоимость одного инструмента на количество бумаг в лоте. Количество в лоте - это параметр LOTSIZE.
Цена одного инструмента - это уже сложнее для части инструментов, но для акций - это просто цена.

В очередной раз инструкция, справка Квика - это вещь в себе.

В чем проблема через известный объем узнать число лотов и подать транзакцию?

Возможно вопрос был про класс "неполные лоты" для которого имело бы смысл знать остаток.

Только не забудьте, что протокол https, т.е. требуется поддержка TSL.

io.popen в окружении терминала все равно поднимает окно.

Не использовать curl из командной строки, а написать библиотеку, клиента, реализующую обмен и передачу информации прямо через http запрос.

Потому что подключение неправильное.

local sqlite3 = require("lsqlite3")


Смотрите примеры http://lua.sqlite.org/index.cgi/dir?ci=tip&name=examples

Собирать надо проект http://lua.sqlite.org/index.cgi/home

Вот собранное https://github.com/nick-nh/qlua/tree/master/luasqlite3 на lua 5.4. В терминале работает.

Немного юмора - видимо, проблема в том, что функционал нельзя реализовать, т.к. это математический термин. Вот и не получается.

Это новая реализация, пока без денег. Потом, как обычно, будет за деньги.

Данный API ничего не изменит, т.к. это средство для разработки. Чтобы его использовать нужен клиент, читай терминал, в том или ином виде. А самый знакомый и уже давно используемый - это Квик.
Вот если брокеры массово начнут писать свои терминалы, тогда возможно. Но это крайне маловерятно. По крайней мере для меня, терминал должен быть не как Web приложение (и даже не на C#), которые сейчас лепят везде, даже там где это бессмысленно.

1С как платформа для роботов - это из области использования сковородки для глажки одежды. Вот как система учета портфеля, сделок, может даже подачи транзакций через файлы и папку обмена Квик - в самый раз. Хотя и это создает ряд сложностей, т.к. это либо установка на конкретном рабочем месте, либо web клиент, что уже требует совсем других затрат на поддержание. Это не говоря уже о скорости работы 1С. Это даже хуже Питона.

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

Как Вы себе это представляете? Терминал - это средство подачи команд. И он отключен, т.е. не может подать команду. Это больше вопрос к брокеру, чтобы он контролировал соединения клиентов и их заявки.

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

Возможно и это. Хотя после восстановления соединения, по идее, данные должны были дойти. Тем более что новые ордера устанавливались корректно, по ним данные приходили. А вот эти старые зависли.
Для обычной пользовательской работы это просто неприятная неожиданность, а вот алгоритм уже не в состоянии адекватно понять, как такое возможно.

Ок. 8-гб не так и много, особенно если параллельно любой современный браузер запущен. Но должно хватать, конечно.

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

Так что еще стоит проверить нагрузку терминала на систему, диск.

Вы бы хотя бы какую-то информацию предоставили - версия терминала, темная или светлая тема, объем оперативной памяти рабочего места, установлен ли антивирус и т.д.

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

Был разрыв связи. Во время простоя заявки исполнились. Восстановление связи. Заявки остались активные. Пришли только колбеки OnTrade. Колбеки на ордера не пришли. Статусы ордеров остались активные.

Версия 11.3.1.2, демо-сервер ARQA

Вот такая замечательная картина. Ордера на покупку.

Примеры не равнозначны, т.к. в первой реализации функции addElement есть вывод элементов, т.е. цикл.


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

Что это значит "динамически меняющего индекс, длину и веса"? Если речь про очередь, стек, то одна задача. Если речь про хранение в массиве определенного числа элементов, скажем 100 и не более, то это другая.

Так и нет ответа, зачем сдвиги, если самое быстрое решение это перезапись элемента и расчет очередного корректного индекса.

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

Для примера, массив на 5 элементов. Значит индекс 12 будет записан в элемент 12%5 = 2

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

Вопрос был не про модель, а про запрос. Впрочем, если это не с первого раза, то лучше руками писать. Хотя, возможно, это Lua - малопопулярный язык, выборка обучения мала.

Интересно какой был prompt, что такой монстр вышел?

Это же форум по проблемам, вопросам, а не про жизнь на Марсе. Плюс почти все уже было обсуждено не по одному разу. Разработчики терминала заняты чем-то еще.
Также стоит учитывать, что терминал рассчитан на MOEX, где торгуют "три калеки", тем более сейчас лето.

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

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

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

Вот, для примера https://www.investopedia.com/articles/investing/102715/computing-historical-volatility-excel.asp

Не очень понятно зачем писать очевидные вещи. Логарифмы как способ изменить шкалу используются очень-очень давно. И финансах в частности. Достаточно вспомнить любой расчет волатильности.

втб котировка 0.022957

Это 22957 пунктов. И когда инструмент расчет, то говорят - вырос на 10, 100 пунктов. Можно уже пункты отнормировать, чтобы цифры были близкие, как это делают при подготовке данных для моделей, например.

В мире финансов принято приводить к единой шкале, в частности к пунктам. Логарифмическая шкала тоже, конечно. Но пункт более универсален и удобен, т.к. это целое число.