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

Ок. 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 мс, ориентируясь на нагрузку ЦП.

Это просто вариация hack_trade. Если речь была про задержку потока main, то да она должна быть. Но секунда как-то много, хотя зависит от задачи, конечно.
Но т.к. в данном примере Robot - это сопрограмма, то не очень понятно зачем там задержка. Чтобы что?

Не очень понятно зачем задержки. При работе с сервером Вы не знаете когда придет ответ. У кого-то связь - GPRS, какой-то брокер не рассчитал нагрузку на сервера. В результате в тепличных условиях ответ транзакции приходит за 200 мс, а в плохих за 10 минут (реальная цифра). Поэтому эта 1 секунда не просто не нужна, а вредна.

Задача состоит из последовательных шагов:
1. Отправить транзакцию.
2. Обработать ответ транзакции.
3. Обработать появление ордера.
4. Обработать исполнение ордера.
5. Что-то еще, например, обработка изменения позиции

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


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


При этом на языке поддерживающим async/await - это можно было бы сделать проще. В Lua мы должны создавать задачи (не важно каким образом) и обрабатывать их квантами, не блокируя и не ожидая какие-то фиксированные секунды.

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

Собственно, чтобы лучше понять как это все должно работать, лучше попробовать работу с базой данных для сотен пользователей. Если заниматься блокировками, то работы не будет, т.к. все будут ждать пока там у одного закончится задача. А если это еще web сервис с тысячами подключений, то и входящие запросы надо обрабатывать.

Может я что-то не понял, но это просто аналогично вызову функции с ожиданием. И теперь представьте что вам надо установить 100 ордеров. Асинхронный подход был бы таким: отправили транзакцию с режимом ожидания ответа, вернулись в основной поток, занимаемся чем-то еще. Начинают приходить ответы транзакций, на них запускаем следующие асинхронные задачи по их обработке. И все это без блокировки. А если я буду ждать ответ от одной транзакции, то пока он не придет, я не могу отправить следующую. В результате эти 100 транзакций вместо 1 секунды, будут уходить минуту.

Да, но все это про переключение между сопрограммами. И если считать, что заканчивать свое выполнение они будут не в том же порядке, что создавались, то притянуть термин асинхронность можно.
Вам надо самому реализовать алгоритм переключения между задачами (thread scheduler). Надо его постоянно вызывать в бесконечном цикле. Т.е. ни о каком фоновом исполнении речи не идет.

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

Lua ни при чем, да. Я вступил в дискуссию только потому, что начали применять термины, уже давно устоявшиеся, в применении к языку. Что может привести к иллюзии, что язык это поддерживает.
Это также как применение функционального подхода к программированию на Lua. Сам язык, в чистом виде, не функциональный. Но если использовать определенные техники и конструкции, то вполне себе можно писать в функциональном стиле. Так и с асинхронностью.

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

Не надо приписывать свойства какому-то определению. Я дал ссылку на, по сути, автора.

Луа не нарушает принципы, а не обладает ими. То что есть сопрограммы, не делает язык Lua полноценно поддерживающим концепцию async/awit.
Вы можете сопрограмму остановить. Вот и все. Из этого не следует, что она асинхронна. В Lua вы все равно будете сами проверять состояние сопрограммы, вызвав ее. Т.е. вы должны написать код так, что будете перебирать все активные сопрограммы последовательно. А вот уходить из очереди перебора они будет не последовательно. Все.

В языках где поддерживается полноценная асинхронная модель, вы не занимаетесь постоянным "дерганьем" сопрограмм. Она САМА сообщит, вызвав колбек. И кардинальное отличие будет в том, что асинхронная функция не блокирует основной код, а в Lua так не выйдет, будете просто переключаться между сопрограммами, остальные заблокированы, т.е. не выполняются.

Вот еще одна статья с картинками https://learn.microsoft.com/ru-ru/dotnet/visual-basic/programming-guide/concepts/async/

Нет. Это не оно.

Асинхронность (asynchrony) часто подразумевает, что операция может быть  выполнена кем-то на стороне: удаленным веб-узлом, сервером или другим  устройством за пределами текущего вычислительного устройства. Т.е. вы передали запрос. Та сторона его приняла, долго выполняла (час), а по окончанию позвонила и сказала - готово. Т.е. есть бригада землекопов, копает яму, а вы на диване сидите, читаете.
Часто это путают с многопоточностью, параллельным исполнением. Что как раз означает, что есть два землекопа и копают одновременно.

Вы же описываете немногопоточный concurrency. Как бы квази-парраллелизм. Хотя этот термин лучше не переводить. Впрочем, если считать, что задача 2 (поставленная позже) завершится раньше задачи 1, т.к. она просто быстрее выполняется, то да, наверно, чисто семантически, разбирая слово (a)sync это можно назвать асинхронностью. Хотя в данном случае просто мы переключались между задачами каждый квант и на вторую ушло меньше квантов, вот она раньше и выполнилась. Собственно в книге автора языка это описано в разделе 9.4. Невытесняющая многонитевость.

А сама концепция async/await была представлена в F# в 2007:

https://learn.microsoft.com/ru-ru/dotnet/fsharp/tutorials/async

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

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

Это не очень нормальное поведение. У меня бывает до 1000 транзакций. Каких-то особых "зависаний" не наблюдается. Впрочем, если Вы активно используете основной поток терминала, т.е. производите действия в колбеках, то вполне возможно, что так и будет. Я придерживаюсь мнения, что колбек это событие, которое необходимо обрабатывать в потоке main скрипта. Кроме как записать в очередь тип события в колбеке ничего не делается. Что касается железа, то я уже лет 15 не работал на машинах где было меньше 16-32 гб и 4 ядер, так что не знаю как терминал реагирует на слабое железо.

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

Правда для светлой темы было такое - https://forum.quik.ru/messages/forum10/message46407/topic3777/#message46407. Ошибку, ниже в той ветке, обещали исправить. Давно не проверял починили ли, т.к. использую все тот же костыль для светлой темы.

Проверьте с новой нотацией <close>, что была введена в lua 5.4

local f <close> = assert(io.open(file, "ab"))

При это руками закрывать файл уже не надо.

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

Для примера, скрипт из сотни тысяч строк и его один цикл занимает до 1 секунды. Реагировать на изменения стакана, когда скрипт занят другим не имеет смысла, т.к. когда скрипт дойдет до разбора, его состояние изменится десятки раз. И все эти промежуточные состояния уже устарели. Но опять, если не стоит задача сохранить состояние стакана в каждый момент времени.

Сборщик мусора не вызывается на каждый тик. Поэтому какое-то время они там останутся.

Передать очень просто. Может прочитать примеры из руководства "Использование Lua в Рабочем месте QUIK". Хотя все очевидно - в колбеке какой-то переменной, записи в очереди, присваиваете какое событие произошло, а в main обрабатываете.

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

Ничего удивительного. Вы в основном потоке терминала (в колбеке таблицы) получаете список инструментов класса SPBOPT, а потом информацию по каждому инструменту.
С учетом того каждый страйк опциона - это отдельный инструмент, то Вы получаете с сервера очень большой объем памяти. И так каждый раз.

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

Проверьте написание функции:
OnCalcul ate

Почему есть пробел. Хотя, по идее, такой код не должен был скомпилироваться. Впрочем, может на графике просто нет индекса 5, дырявый график.

Да, это я пропустил взглядом эту строку. Советую просто вывести данные полученных параметров в лог, чтобы оценить что конкретно передается при вызове AddLabel.

В качестве второго параметра os.date принимает число (unix time), Вы же передаете таблицу.

Сегодня не подключиться к демо-серверу, пришет "Срок лицензии истек". Ранее фраза была другая, да и с 26.02 (когда доступ получался) прошло менее месяца.
Сделайте уже в форме запроса доступа флаг с автоматическим продлением доступа и, если угодно, контроля последней активности. Если последняя активность более месяца назад, то тогда и отключать доступ.


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