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

У меня итак timeout 120 секунд. Версия 12 терминала. самая стабильная была 7-ая. А дальше поехали мажорные версии через месяц.

Вот такую картинку получил при отладке индикатора с интенсивной записью в лог

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

Delphi не было желания изучать. В мое время был TurbоPascal или чистый С.

У меня wnd не сохраняется даже без ключа /f
Поэтому вопрос и возник. Проблему с скриптами нет, т.к. они могут сами остановится к нужному времени.

Этот метод - это принудительное закрытие. Я его использовал. При перезапуске состояние не восстанавливается.

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

Желательно без сторонних изделий времен Delphi.

Предложите способ корректного выключения терминала по времени. Возникла задача останавливать все в определенное время.
Но способы через скрипты Power-Shell, CMD использующие Stop-Process, taskkill - приводит к некорректному завершению терминала, без записи состояния.
Нужен способ, чтобы терминал выполнил все действия при завершении.

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

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

Что касается разного времени для секций, то естественно необходимо хранить разные отметки по классам, секциям. Т.к. даже внутри одной фондовой секции разные времена - 7 утра для части акций, 9 - утра для ОФЗ, и 10 утра для всех. Зачем это сделано - это вопрос в палату. Но раз сделано, то сделано.

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

Нет, календарный спред на ММВБ - это два контракта с разной датой экспирации. Если цены будет равны, то 0. Если беквордация, то отрицательные цены. У опционов такой спред если только самому делать.

https://www.moex.com/ru/spreads

UID = 6672314

Последний раз перемешивание индексов произошло 15-07-225 в 19:52:59.

Сегодня два раза в 12:58:45 и 13:24:03 был разрыв соединения с вызовом OnCleanUp, но уже без перемешивания. Но вопрос зачем OnCleanUp тоже есть.

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

Это происходит у брокера Сбербанк (сервер у него один) в середине торговой сессии когда сервер брокера разрывает соединение, а после восстановления вызывается колбек OnCleanUp.
Версия терминала 12.2.2.8

Проверять на 0 цены - это плохая затея, т.к. во-первых, есть инструменты с допустимой ценой = 0, а во-вторых, для срочного рынка во время клиринга, для фондовой между сессиями цена может "бегать" от 0 до последней.
Собственно в период, когда торги не идут, данные с сервера могут приходить какие угодно. Так что уже лучше время проверять, обеспечив точность своих часов.
У меня сделано через несколько проверок, время, статус, сделки. И если один из них не проходит, то данные не считываются, т.к. получить цену 0 как рабочую - это проблема для алгоритмов.

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

Времена часто изменяются. Они на сайте биржи в разделе расписание торгов есть. У Валютной секции совсем другие времена, для примера.
Так что да, надо читать самому статус, правда здесь тоже есть проблема, т.к. флаги приходят с явными задержками, особенно с CLSTATE в вечернюю сессию. Очень часто до 2-х минут задержка.
С TRADINGSTATE получше, но тоже задержки до 10-15 секунд.

И почему-то очень часто вижу, что время вечерней сессии 19:00, хотя 19:05 на самом деле, если нет другого сообщения. Это на фондовой секции в 19:00 начинается вечерний аукцион открытия, сама же сессия тоже в 19:05.

В ТТТ объем общий, можно вывести параметр общее количество и умножить. Сделки же есть и внебиржевые.

Сложно сказать не видя контекста.
Расчет простой, например Сбер - цена 300 * 10 лотность * число лот. Т.е. один лот стоит 3000 руб. Поэтому каждая сделка в 1 лот увеличивает денежный объем на эту величину, 10 лот - 30 тр.

В ТТТ есть два параметра

VOLTODAY - Количество бумаг в сделках

VALTODAY - Оборот в деньгах


"Т.е. умножение объема на лотность и хай дня по цене значительно меньше оборота из ТТТ. Этого не понимаю" - они и не должны быть равны. Максимум цены мог быть достигнут одним лотом, а большая часть объёма прошла ниже. WVAP цена (параметр WAPRICE) будет в итоге ниже, может даже значительно.

Количество бумаг, а не деньги.

Когда-то очень давно писал такое  https://github.com/nick-nh/qlua/tree/master/quantScript

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

Все же пока это происходит только после OnCleanUp, а не вдруг.

Явно не из-за этого. В Lua строка - это "immutable sequences of bytes". Т.е. не важно что там. Плюс, начиная с версии 5.3, есть базовая поддержка UTF8 https://www.lua.org/manual/5.4/manual.html#6.5

Если использовать Lua вне экосистемы Quik, то прекрасно работают файлы с кодировкой UTF-8. Тот же редактор ZeroBraneStudio работает в UTF-8, и не поддерживает win1251.

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

Что значит новые. С утра установлены заявки, они получили индексы в таблице ордеров. В 12:30 брокер разрывает связь, тут же восстанавливает, но при этом вызывает колбек OnCleanUp.
Все таблицы очищаются. После происходит восстановление записей в таблицах (при этом приходят все колбеки заново).
Далее смотрим на эти записи и видим, что ордер с индексом 15 стал 20. И так по всем записям - все вперемешку. Смотрим на таблицу ордеров в интерфейсе, там порядок записей такой же ка был изначально.

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

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

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

Более важно другое, после восстановления соединения в таблице ордеров наблюдаются совсем другие индексы записей. Был у записи индекс 15, а стал 20.
Хотя визуально таблица (без фильтров и сортировок ) представлена именно как была ранее, и там запись до сих пор 15.

Ранее такого поведения не наблюдалось. Сейчас приходится вводить дополнительные методы для восстановления соответствия записей и запомненных данных.

Так купите другой терминал - ATAS, Tiger, Go Invest. Назвать их супер удобными и быстрыми сложно (т.к. эти изделия заточены под графики и руки, а не алгоритмическую торговлю), но альтернатива так сказать. Также ещё остался Финам с возможностью торговли через MT5. Есть ещё Алор c своим web-поделием.
Т.е. если есть задача найти решение проблемы, то даже сейчас это можно сделать.

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

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

Проблема в этом https://disk.yandex.ru/i/-GHF6orcG8COlA

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

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

Впрочем, Вам явно необходимо высказаться. Вот пример без расчёта на каждый тик. И он точно также "убивает" терминал. У Вас работает, у меня нет. Поэтому мне интересно мнение разработчиков.

Код

local lines = 100 Settings = {} Settings.Name = "*test_lines" Settings.price = 313 Settings.delta = 0.01 local cache = {} function Init()     Settings.line = {}     for i = 1, lines do         Settings.line[i] = {}         Settings.line[i] = {Color = RGB(185, 185, 185), Type = TYPET_BAR, Width = 2}     end     cache = {}     return lines end function OnChangeSettings()     Init() end function OnCalculate(index)     if index < Size() then return end     if cache[index] then return end     for i = 1, lines do         SetRangeValue(i, index-100, index-1, Settings.price-i*Settings.delta)     end     cache[index] = true     message('calc '..tostring(index))     return end

Все же эта тема посвящена конкретной технической проблеме терминала.

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

Пример именно такой, какой нужен, т.к. я по большей части вывожу данные назад по барам, т.к. алгоритм не предполагает простого линейного расчёта.
Иначе можно говорить, что теперь у методов установки данных на график есть ограничения. Или проблема, что более вероятно, т.к. при добавлении оного на график потребление ресурсов процессора повышается с 0% до 9-10%.
Что тоже не много, но терминал уже не отвечает.

В последних версиях терминала если добавить индикатор где число линий, например, больше 50, то терминал просто "умирает". Этот же индикатор в 7-ой версии вполне себе работал, даже не на одном графике.

Вот простейший пример, ничего, по сути, не делающий, а просто выводит линии на график, демонстрирующий проблему.

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

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

Что-то типа такого:

local on_param = SubscribeOnParam({'SBER', 'GAZP', 'SiU5'}, {'LAST', 'BID', 'OFFER'})

Т.е. мне не интересны другие коды и параметры. И таких подписок делать много, вплоть до одного инструмента, параметра.

Пусть эта реализация будет внутри терминала, и не влияющая на получение информации. Например, поток данных заходит в очередь, а сформированные колбеки её разбирают. Желательно отдельным потоком.
И так для любых таблиц терминала.

Но это, как говорится, совсем другая задача. Кодировка до сих пор 1251, чего уж говорить об этом.

В Квике есть параметры:

NEXTCOUPON - Дата выплаты купона
COUPONVALUE - Размер купона
COUPONPERIOD - Длительность купона

Ну это очень древний вариант.

Надо тогда сдвинуть очистку данных ниже проверок.

SetValue(index-bars-barsshift, 1, nil)

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

if calculated_buffer[index] ~= nil then

Да, если есть колебательный процесс, то есть соблазн представить поступательные движения тренда как фазы волны с большим периодом. А внутренние колебания (по сути шум) как гармоники.
Эта идея не нова, а у же с середины 90-х заезжена вдоль и поперек. Помню как радиофизики тогда с придыханием говорили, что вот сейчас придём и научим всех как надо.
Доля смысла есть в этом подходе, но только пока процесс не изменится. И сразу всё ломается, т.к. цена не обязана идти по ряду Фурье. Если бы временной ценовой ряд можно было представить аналитически, то, наверно, это уже давно бы сделали. Так что да, такой подход возможен, но тогда необходимо постоянно пересчитывать модель.Я не понял смысл этой фразы, сути проблемы.

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

Например ema - фильтр, где используется прошлое значение, полученное на текущем окне. Хотя да, это уже строго говоря не скользящее окно.
На скользящем окне Вы каждый раз рассчитываете результат по данным этого окна, не смотря дальше. Но с другой стороны, если окно изменить, то можно получить резкий скачок в данных. Было окно 100, стало 10. Результат уже явно другой. Т.е. цель изменения окна - это изменить работу фильтра для всего сигнала. А если изменять его туда-обратно, то как такой сигнал потом интерпретировать.

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

Это Вы может делать только если данные независимы. А если окно скользящее, с зависимостью, что изменяя "на лету" окно ничего хорошего ожидать не стоит.

Идея сглаживания - это борьба с выбросами.  Как только Вы начинаете бороться с запаздыванием, то сразу возникает вопрос: а зачем тогда сглаживать? Тогда лучший - это просто сам график. Запаздывания нет.
Ну и прежде чем браться за идею, стоит понять к чему приводит сглаживание. Это хорошо видно при преобразовании Фурье. Вот здесь очень наглядно про это https://rutube.ru/video/beeb00abb33061f14a37f54d3536a10b/

Т.е. если браться за фильтрацию сигнала, то сначала необходимо определиться для чего.

Значит есть ошибки. Встроенные индикаторы в терминал - это не то же самое, что библиотека индикаторов INDICATORS.zip
Встроенные, работают корректно.

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