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

Плюс, возможно, еще нужен НКД - это параметр 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 пунктов. Можно уже пункты отнормировать, чтобы цифры были близкие, как это делают при подготовке данных для моделей, например.

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

Скорее всего это проблемы колбеков, если их используете. Правда не написали какая версия qlua. 5.3 вышла не очень стабильной.

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

Кажется уже недавно был такой вопрос.

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

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

Я никогда не использовал русскую локаль в любой среде разработки. Это на самом деле очень неудобно.
Но есть стандартная инструкция https://code.visualstudio.com/docs/getstarted/locales
Надо просто установить необходимый Language Pack.

Это, возможно, удобно если проект - это один файл. А если проект - это несколько каталогов с десятками файлов, при этом каждый проект использует разные, то уже все не так удобно. Хотя если command.build позволяет запустить свой скрипт сборки, то возможно. Хотя я все одно не вижу преимуществ перед ZeroBrane Studio. VSCode настолько прост, что даже не очень понятно, что может быть сложным.

Немного не в тему, но все же я не очень понимаю зачем использовать встроенную команду компиляции. Это не считая самого редактора SciTE как такового. Он, по сути, простой блокнот.
Я скрипты компилирую через терминал, с использованием специально написанного (на том же Lua) скрипта компиляции. У меня проект - это много файлов, каждый раз разные зависимости. Руками это компилировать?

А что касается среды разработки, то она нужна для контроля качества кода, обязательной поддержкой Git, переходам между модулями, определениями методов, проверки на ошибки кода. А если пишешь на чистом Lua, то чтобы была и отладка. В этом плане ZeroBrane Studio, как редактор Lua, лучше. И это не считая Vim, Emac, VSCode, IntelliJ IDEA, lite,  А если редактор - это просто подсветка синтаксиса, то для Windows гораздо проще использовать Notepad++

Вот, для примера https://github.com/nick-nh/qlua/tree/master/invest_battle_pro

Спросите своего брокера почему такой код класса. По крайней мере будет ясно, что это за класс, противоречащий спецификации.
Разработчики терминала вряд ли подскажут, почему в базе данных брокера такое значение.

Отдельного метода именно для таблицы depo_limits нет.

Ну так уточните у брокера ВТБ, что это за класс, противоречащий спецификации. Впрочем, это может быть какой-то специфический класс, типа неполный лот, заблокированные и т.д.

Сомневаюсь, что это торгуемый класс, а не информационный.

По крайней мере, такого класса в списке API биржи я не вижу.
https://iss.moex.com/iss/engines/stock/markets/shares/boards.txthttps://iss.moex.com/iss/engines/stock/markets/shares/boards/TQTF/securities.txt


Да и 4-е символа обычно.

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



Спрашивается, почему значения полей отличаются. В одном случае "Покупка", в другом "Купля". "Комментарий", "Примечание". "Торговый счет", "Код торгового счета"...
Где отдельное поле "Код клиента" для фондовой секции, тот что CLIENT_CODE.

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

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

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

По опыту, если есть окно скрипта, то задержка не меньше 50 мс. Если его нет, то можно и 10, даже 5 мс, ориентируясь на нагрузку ЦП.