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

nikolz, я думал, у Вас всё на роботах, и индикаторы оказываются не нужны. Зачем Вы их используете, если не секрет, да ещё 20 линий в одном индикаторе?
Я, например, облако скользящих строю. А на графике (вместо чисто внутри робота) для наглядности, т.к. ещё только приступаю к автоматизации ТС.

Так нужно, т.к. в файлах настройки есть прямые пути к файлам.

Если это вдруг помогает, то это сервера у брокера тормозят, а не у Вас что-то не в порядке.

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

Адресуется разработчикам (что они рекомендуют исходя из архитектуры, были ли у них внутренние тесты, что быстрее работает) и к тем пользователям, кто этот вопрос проверял.

На сколько я понимаю, IMOEX2 "% к предыдущему закрытию" считается к закрытию IMOEX, а не IMOEX2

Торгуете изнутри индикатора? Тогда в лучшем случае добавить на график область с price от наиболее ликвидного инструмента того же класса, тогда и на Вашем инструменте во второй области добавятся тики от того инструмента (с ценой nil). Конечно, о привязке к таблице текущих торгов можно забыть тогда, т.к. она будет заменять все инструменты на графике.
Торгуете из скрипта? Тогда цикл у Вас всё равно есть, внутри него проверяйте os.sysdate(), учитываете разницу во времени и м.б. пинг до сервера, если надеетесь на миллисекундную точность.

QUIK в одном потоке интерфейс держит, включая все таблицы, созданные не из юзерскриптов, и индикаторы. В 5800X 8 ядер, т.е. 12.5% загрузки всего проца значит полную загрузку ядра, на котором квик. Остальные Ваши 2.5% идут от других программ, или от юзерских скриптов в квике.
Основное, что мне помогло в ускорении квика, - это удаление старых свечей из archive/*.dat (чтобы на графиках и в datasource'ах не было много свечей), + уменьшение частоты обновления "Изменения биржевых параметров" до 3 сек с 1 сек + уменьшение количества графиков и индикаторов на них.

В 10.1.2.2 этот пункт тоже неактивен для спец формы.

Если так сделать, и не устранить задержки в трансляции, из-за которых эти "дубли" появляются, то будут приходить сделки из прошлого (как в примерах выше по 9 штук в одну из минут) с соответствующими изменениями номеров старых свечей и/или индексов в datasource. Лучше оставить как есть

Andrey Bezrukov,
а долго ждать-то? Техподдержка биржи вроде бы обычно быстро отвечает

У Вас воспроизвелась проблема?

Я делаю так: юзаю lua_share (для использования достаточно знать Lua, хотя сама библиотека написана на дельфи), в сервере пишу через lua_share в общую память, в индикаторах читаю из общей памяти. Ну и наоборот тоже можно. Один сервер на 14 графиков совокупно с 20-ю областями, в каждой из которых используется 2-3 индикатора-потребителя данных.

OnChangeSettings не вызвать просто так.

А, вот и причина, почему БКС не обновляет версию терминала квика с 10.1.2.2...

Вы быстрее отреверсите, тем более что контроль полный над заявками и сделками. archive/*.dat точно легко отреверсить.

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


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

Собственно, сабж. Сменил язык (хотел в кармане транзакций и в .tri файле видеть английские названия и значения полей, а не русские), QUIK рестартовал, а теперь не могу (даже после ещё одного рестарта):

1. Сменить язык назад (при нажатии на System-Settings-Language settings... ничего не происходит)
   
2. Соединиться с сервером (System-Connect... или Ctrl+Q или кнопка на панели -- ничего не происходит)
   
3. Вызвать настройки (F9 или System-Settings-General Settings... -- ничего не происходит)
   

Для теста хотелось бы соединиться с сервером. Есть способ это сделать?
Если нет, где найти ВСЕ английские названия параметров транзакций? Например, для "Тип стоп-заявки=Тейк-профит и стоп-лимит" есть параметр "Флаги=258", но в описании в "6.9 Импорт транзакций" я его не вижу даже в последней версии квика.

"по вашему вопросу, касаемо задвоения сделок по индексам в «таблице  обезличенных сделок» поступил ответ от специалистов: такие данные  поступают в КВИК от биржи."

Значит ли это, что биржа права?) В методике они пишут, что расчёт раз в секунду идёт. Но не пишут, что трансляция раз в секунду идёт. Хитрые какие. В прошлый раз мой запрос по трансляции к ним напрямую (по другому поводу) они отфутболили к брокеру.

Отправил архив, сегодня тоже нашлись дубликаты.

Именно так. Список дублей 18.07 (архива нет) был такой:

Скрытый текст

сервер 195.85.206.122:15100 IMOEX duplicates: 10:12:19 16:01:13 16:01:45 16:01:46 16:01:47 16:01:48 16:01:49 16:01:50 16:01:51 16:01:52 RTSI duplicates: 16:01:39 16:01:45 16:01:46 16:01:48 16:01:49 16:01:50 16:01:52 сервер 195.226.204.208:15300 IMOEX duplicates: 10:00:04 <- подтвержден БКС 16:01:31 16:01:40 16:01:45 16:01:46 16:01:47 16:01:48 16:01:49 16:01:50 16:01:51 16:01:52 RTSI duplicates: 10:00:04 <- подтвержден БКС 15:39:08 16:01:39 16:01:47 16:01:48 16:01:50 16:01:51 16:01:52

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

Архив отправил. Надеюсь, после выходных про него не забудут :)

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, так как визуально сейчас не отличаются индикаторы, нарисованные "барами" и "свечами"

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