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

Я не использую Дзен, так что, видимо, это не про меня.

Что касается примера, основной вопрос - зачем? Какую задачу это решает. Создавать объект ради объекта - это тупиковый путь, хоть и популярный лет 20 назад. А во многих языках даже обязательный.
Но это не относится к Lua. Да, здесь многое завязано на таблицы, если не почти все, если считать _G. Но это не значит, что нет других объектов first class citizen.

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

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

Без примера, сложно что-то ответить. Любая переменная доступна для изменения в своей области видимости.

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

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

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

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

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

А это здесь уже не важно. Время открытия бара это данность. Если бар есть, то и время есть. Если бара нет, то это пустой бар и надо просто взять ближайший. Все зависит от необходимой методики определения.
Если надо определить индексы баров для времени 10:13, то для минутки это будет точное совпадение. Для 2-ух минут - бар 10:12. Для трех, четырех тоже  - 10:12. Для 5-и 10-и минут 10:10. Для 30 минут часа 10:00. Для двух часов зависит от кратности часа. И т.д. Всегда можно найти ближайшей бар к искомой точке.

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


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

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

Я же написал, что это упрощенный вариант. Выше писал, что надо учитывать ситуации когда искомая точка находится внутри бара. В данном случае время 09:00 будет внутри бара 08:00-10:00.
Т.е. надо добавлять еще проверку на границы, останавливаться когда одна из границ это начало искомого бара.

Это элементарная рекурсия. Есть первый вызов с 1 и ds:Size(). А потом каждый раз делится пополам интервал.

Вот простейшая реализация

Код

local function is_date(val)     if type(val) ~= "table" then return false end     local status = pcall(function() return os.time(val); end)     return status end local function get_time_index(ds, time)     local bs     function bs(bi, ei)         local i2 = math.ceil((ei-bi)/2) + bi         while not is_date(ds:T(i2)) and i2 < ei do             i2 = i2+1         end         if not is_date(ds:T(i2)) then return end         local t = os.time(ds:T(i2))         if ei - bi == 1 then return ei, ds:T(ei) end         if t > time then return bs(bi, i2) end         if t < time then return bs(i2, ei) end         return i2, ds:T(i2)     end     return bs(1, ds:Size()) end local ti = get_time_index(ds, os.time({hour = 9, min = 33, sec = 0, day = 1, month = 11, year = 2023})

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

Не очень понятна проблема. Есть точка времени, есть массив времен. Все это натуральные числа os.time(ds:T(index)).
Т.е. все сводится к простой задаче - найти индекс в массиве с нужным числом. Как выше написал - двоичный поиск быстро найдет. Правда, конечно, функция сравнения должна быть не на равенство, а на вхождение искомой точки в диапазон бара. Например для 10 минутных баров, точка времени 10:03.

Ну ее нет, так что надо её написать и забыть.

Что касается математической оценки серии сделок, то это тоже давно все формализовано. Вот, для примера, https://www.mql5.com/ru/articles/1492

Ну это, видимо, современная деформация, когда слово самообучение воспринимается как AI. Хотя та же кластеризация ( которой уж сколько лет) тоже накапливает данные и "как бы" учится.

Я и не советую никакой AI. Если задача просто посмотреть что получилось и ничего с этим не делать, то и нет проблем. Задача простая.

Да, предполагается, что надо этот индекс найти. Двоичный поиск вполне быстро найдет его, надо просто перейти на числовое представление времени (unix time).
Почему найти, потому что когда у Вас уже 65000 тыс. бар, то при переподключении к серверу удивительным образом нумерация баров "съедет", т.к. произойдет сдвиг, чтобы не выходить за пределы доступного объема массива.
Поэтому индекс сегодня не обязательно будет тот же, что и вчера.

Не очень понятен вопрос. Как получить бар, зная дату и время?

Попытаться привести к стационарному виду Вы, конечно, можете. Правда не забудьте потом работу написать...

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

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

Не надо полностью все поля писать кириллицей. Напишите только это поле так.

Наверно, все же, стоит прочитать документацию. Методы getIem, getNumberOf и SearchItems из этого раздела не предназначены для работы с таблицами, созданными через метод AllocTable.

Чтобы было понятнее - раздел документации 3.1 Функции для обращения к строкам произвольных таблиц QUIK.
Функции из этой группы предназначены для доступа к данным, содержащимся в таблицах Рабочего места QUIK. Т.е. это встроенные таблицы терминала.

В методах есть параметр TableName. Список возможных значений этого параметра в документации тоже представлен.

Не тратьте свое и чужое время попусту.

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

И такое возможно. Также можно просто писать в файл. Просто нужен любой прокси.

Я Вам уже в прошлый раз написал, что прямого способа нет. И это отбрасывая вопрос зачем это вообще надо делать. В метку Вы можете сохранить text (текст), hint( подсказку) - это строки, цену, дату-время. Т.е. метка может дать информацию о том где она находится на графике и какой текст в ней сохранен. Что потом можно и прочитать, ЗНАЯ ЧИСЛОВОЙ ИДЕНТИФИКАТОР ЭТОЙ МЕТКИ, который, к слову, может произвольно изменится.
Что касается документации, то она может не идеальна, но как минимум дает представление о том какой формат вызова у метода, какой тип данных метод возвращает. Прочитав это, отпадут вопросы о том почему не работает передача в параметре метода, например, строки вместо числа.

Вы упорно, по какой-то причине не хотите читать документацию, даже пример, что был приведен выше.

В методе AddLabel передается таблица параметров метка в определенном формате. И там нет такого параметра как secCodeLabel.

Может Вы все прочитаете документацию по синтаксису языка, по методам qlua.

Зачем при объявлении переменных в таблице label_params используете ключевое слово local?

Далее, вызов NUMBER AddLabel(STRING chart_tag, TABLE label_params)

Как видно из сигнатуры, метод возвращает число - это идентификатор добавленной метки на графике. Если вернулось nil, то метка не добавилась. Вот Вам пример https://luaq.ru/AddLabel.html

Далее, GetLabelParams("goodmode1", "Метка")
Читаем документацию: TABLE GetLabelParams(STRING chart_tag, NUMBER label_id)                        

Т.е. метод возвращает параметры метки - таблица, а принимает идентификатор графика - строка, идентификатор метки (тот, что вернул метод AddLabel) - число.

Можно, конечно, и так пробовать, но потратить 10 минут на чтение - быстрее.

Конечно, если на каждый бар, тик выводить message и не это еще будет. OnCalculate вызывается минимум два раза при добавлении индикатора на график. И столько же будет выведено сообщений.
Если баров на графике, например 30 тыс., то не удивительно.

Кажется Вам уже отвечали (может и не Вам, но была похожая тема), что метод getDataSourceInfo предназначен для индикаторов, а не скриптов. Это разные концепции в контексте терминала.

Ваша задача - из скрипта по назначенному графику идентификатору получить код инструмента, который на данный момент назначен на график.
Ответ - прямого такого метода нет.

Можно решать косвенно:
1. Метод getCandlesByIndex возвращает легенду графика. Это подпись графика, которая может содержать код инструмента, но чаще его краткое имя. Так что это не очень надежно.
2. Можно написать индикатор, добавляющий и обновляющий метку на график, где в тексте или подсказке добавить всю нужную информацию. А уже из скрипта прочитать данные этой метки.

Елена, это следует из синтаксиса языка. Когда Вы пишите, инициализируя ключ в таблице (или просто в коде):

local trans = {
...

BASE_CONTRACT = GAZR,
...

}

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

В результате BASE_CONTRACT становился nil.

А вот в таком виде
BASE_CONTRACT = "GAZR"

Уже означает, что переменной необходимо присвоить значение типа строка = "GAZR". Что и следует из того, что все коды инструментов и классов - это строки.

В таблице текущих торгов выведите информацию об инструменте и увидите код базового актива. Также его можно получить через метод getSecurityInfo.

Все как обычно. Просто класс инструмента CETS код инструмента USD000UTSTOM

А вот с учетом позиции уже есть особенность, т.к. размер лота = 1000.

Откройте демо-счет и сможете все детально проверить.

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

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

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

Я, конечно, не знаю давность информации и конфигурацию оборудования, но вот это: "Пропускная способность не сильно производительного mssql сервера примерно 1500-2000 транзакций в секунду" вызывает сомнения.
20-30к в секунду - это нормально. Бывает и 200к.

А если взять другие базы данных, то там 100-200к - это просто норма, не говоря уже про документные базы. Если бы, для примера Quik был на NYSE, то при 1,5к - просто все встало бы.
И, кстати, оставаться сейчас на транзакционной базе данных для прокси сервера, уже выглядит странно.

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

Если ли доступ к таблицам, создаваемым модулем TrustManager из qlua?
При подключении модуля появляется тип транзакции NEW_GROUP_ORDER, судя по экспорту. Поэтому и возникает вопрос - как сформировать команду, читать данные и т.д.

Нет идеальных решений. Я Питон и его колхоз терпеть не могу, но полмира пользуется и довольно.

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

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

Если Вы, действительно, хотите разобраться, то, наверно, все же стоит прочитать сообщения, что были написаны. А еще лучше документацию. В ней указаны все методы и, что важно, - сигнатуры вызова методов.
Уже было сказано, что метод getDataSourceInfo вызывается без параметров. Этот метод доступен в контексте индикатора.
Метод же getSecurityInfo - получает данные по переданным параметрам класс инструмента, код инструмента. Кои Вы и хотите узнать, а значит и использовать getSecurityInfo не получится.

И еще раз - по идентификатору графика можно узнать значения линий этого графика, а что это за график (и какого инструмента) нет.

getDataSourceInfo выдает информацию о графике, в котором он вызывается. Т.е. есть индикатор, нанесенный на график, в нем есть метод getDataSourceInfo. Вот по этому графику и будет информация.
В руководстве показана сигнатура вызова:

TABLE info getDataSourceInfo()

Никаких параметров. Т.е. метод не предназначен для получения данных о другом графике по идентификатору. Такой вызов некорректен.

getDataSourceInfo - это метод qlua.

График предоставляет данные о линиях, выведенных на него. Раз это Price, то и будет выдана информация о барах этой цены. А чья эта цена метод getCandlesByIndex (если используется он) не предоставляет.

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

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

Я уже все выложил. Даже видео работы записал. Разработчики его увидели. Зачем мне что-то еще доказывать для Вас. Вы говорите что нет проблем, у меня же тот же скрипт на чистом демо квике выдает обратное. Себе я верю больше.
Тем более, что Вы видоизменили процесс вывода, убрав подсветку, убрав заполнение значения в ячейку, оставив только его представление.
Если разработчики скажут, что у нас есть проблема с выводом числовых значений, то да.

Не у всех. Проблема в особенностях скрипта. Скрипт может быть корректным, но будет воспроизводиться проблема. Переписав скрипт по-другому, проблема уйдет.
Но это не отменяет факт разного поведения в разных темах, различиях в поведении в зависимости от места вызова SetSell. Впрочем, с Вами спорить бесполезно. Тестовые скрипты уже были предоставлены, поддержка написала "Проблема изучается" и "Будет исправлена" https://forum.quik.ru/messages/forum10/message49120/topic3777/#message49120.

Я решил вопрос для светлой темы. Кто-то так и не смог из-за особенностей их скриптов.

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

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

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

Я ничего не говорю про точки входа, алгоритмы и т.д. Я говорил про написание своего итератора (https://www.lua.org/pil/7.1.html) , позволяющего писать что-то типа такого:

while ds_list:Next() do

При этом у каждого ds в списке можно написать свой колбек на приход нового индекса. Тогда код становится еще более простой, в функциональном стиле.

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