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

https://1drv.ms/i/s!AuoSTm_J34NqiVyZBvK5U-9WXz9B?e=QFJwFa
залил скриншот на onedrive, RTSI и IMOEX2. На IMOEX так же, как на IMOEX2 (в частности, в 16:00 объём по 23 и там, и там)

Объём минутных свечей текущего дня не зависит от этой настройки у меня, и он всегда <=60. На RTSI даже видно в 16:00 был объём 19. Я бы ожидал, что в каждую минутную свечу объём 59-60 был нормальным. А лучше вообще всегда ровно 60, т.к. биржа считает эти индексы как минимум раз в секунду.

Спасибо за пояснения!

Спасибо, в 10.3 действительно полная документация по этому вопросу.

3 секунды, то есть по крайней мере для индексов эта часть логики не работает. Когда стояла 1 секунда, тоже было не 60 стабильно.

В любом случае, спасибо за развёрнутый ответ! Ранее ТП брокера ссылалась на эту тему для ответа на мой вопрос.

Пока что я предполагаю, что сервер QUIK (у брокера, не у ARQA и не у биржи) получает от ТС (брокера, не ARQA, не биржи) не все обновления, или не может все полученные оттранслировать. Или есть какой-то центральный сервер QUIK (у ARQA или у биржи), который от биржи чего-то не дополучает или получает всё, но не может остальным оттранслировать полностью?

Здравствуйте.
Версия 10.1.2.2.

В документации к getParamEx, getParamEx2, ParamRequest, CancelParamRequest и CreateDataSource фигурирует имя параметра Таблицы текущих торгов, но нигде в документации по qlua нет ни списка этих параметров, ни информации о том, где их брать. Благодаря этому сообщению выяснилось, что есть некий список в документации к qpile, но там он не полный. В частности, из сообщения видно, что существует параметр COMPLEXPRODUCT (и вроде бы он, равно как и его имя, устанавливается биржей), а в списке параметров для qpile в разделе 8 info.chm такого параметра нет, равно как и QUALIFIED.

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

Всё ещё жду ответа техподдержки.

Здравствуйте.
Поясните, пожалуйста, этот ответ. "Измеряется он в штуках" -- кто "он"? Кто рассылает эти данные объёма -- биржа, ARQA, или брокер? Если исходные данные в рублях и лотах, кто-то должен пересчитать их в то, что приходит пользователям,  и перетранслировать.
В любую минутную свечу объём по индексу приходит от 1 до 60. Часто меньше 55. Что это за лоты такие? Выглядят как секунды, в которые было обновление. Неужели есть секунды на утренних торгах, когда ни по одной индексной акции нет сделок? У меня, собственно, потому и вопрос, что кажется, что не все данные приходят.

Версия 10.1.2.2
Дано: график с двумя областями, в одной инструмент имеет свечек больше,  чем во второй, из-за чего во второй области, когда всё загружено, видны  гэпы. Пример - EUR (данные с форекса у меня транслируются откуда-то) и  SiU3 (или фьючерс и базовый актив, или RTSI + IMOEX2). Таймфрейм 1 или 5 минут, торги активны. На том инструменте, где есть гэпы,  ставим два индикатора с одинаковыми параметрами (кроме может быть визуальных) - встроенный SMA и SMA из официальных примеров индикаторов, с изменением для определения скачка номеров свечей:
Этот индикатор должен быть одним из верхних (значит - приоритетных) в области.
Нажимаем Ok после добавления индикаторов. Если в сообщениях не появилось про гэпы ничего, но они есть, меняем таймфрейм туда-сюда между 1 и 5 минутами, рано или поздно у меня появляется сообщение в духе:
gap at 6061 Fri Jun 16 14:40:00 2023, jump from 4139
Почему? Потому что, видимо, квик случайным образом выбирает, какую область графика рисовать первой: ту, где гэпы возникнут после отрисовки всех областей, или ту, где свечей "больше". Если сначала рисовать более "полную" область, то во второй области индекс не прыгает, просто для отсутствующих свечей будет C(Index) = nil. Если сначала рисовать менее полную область, то индексы сначала не прыгают, все C(Index) ~= nil, потом грузится вторая область, потом при новых данных OnCalculate(Index) начинает получать внезапно большой Index (дебаг принты через PrintDbgStr номеров свечей и их времени):
... и при обращении к старым индексам уже можно получить C(i) == nil, т.к. попадёшь на гэп.

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

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

tostring(res) потому что для булевых значений

На днях как раз натыкался на пример 8-летней давности: https://github.com/boscogh/quik_pipe

Со времён этого поста ничего не поменялось, судя по всему.

Если в файле индикатора задать тип линии по умолчанию так
, то при добавлении индикатора тип линии окажется просто "Линии", то есть TYPE_LINE. В документации "Интерпретатор языка Lua. Руководство пользователя. Версия 10.1" на странице 113 такая константа указана, и сказано, что она рисует бары, а не линии. Я знаю, что полноценные бары нельзя пока передать на рисование, но зато если выбрать "Бары" или "Свечи" через меню, то индикатор рисуется наиболее подходящим мне "пунктиром". Если выбирать "Пунктир"  или "Пунктир-точка", то при увеличении масштаба индикатор сливается в линию быстрее, чем если рисовать его "барами" или "свечами".
Предлагаю убрать эту константу из документации или добавить равной TYPE_CANDLE, так как визуально сейчас не отличаются индикаторы, нарисованные "барами" и "свечами"

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