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

Если уж уделяете столько времени этому вопросу, то, наверно, стоит сделать устойчивый вариант. Ошибка же была о сравнении nil с числом.
А во всех предлагаемых реализациях нет проверок на наличие бара, полученных значений перед арифметикой, перехвата ошибок, чтобы Квик не умирал от потока сообщений об ошибках на графиках с 60 тыс барами и т.д. Даже если отбросить саму реализацию, то это все не рабочие решения.

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

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

Ошибка заключается в том, что если график содержит дырку, т.е. нет бара в отсечку времени, то H и L выдадут nil.
А nil нельзя сравнивать с числом. Поэтому необходимо проверять, что вернули H и L. И если это nil, то пропускать такое, переходя к следующему бару.

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

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

   local max_high = High(index - kijun_period + 1)
  local min_low = Low(index - kijun_period + 1)

Вот строки. Вместо High и Low, H и L

Ну ошибка же очевидна - В Квике нет методов High и Low, есть H и L.Открываете любой, так всеми рекламируемый ИИ, и просите исправить. С такой простой задачей он справится. Хотя терминал Квик для него, конечно, совсем экзотика.

Не проще ли сделать цвет линий встроенного индикатора = цвету фона окна и сдвинуть бары выше индикатора, чтобы линии не были видны на барах.

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

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

И даже в этом простом коде ошибка - код обработки файла конфигурации не соответствует структуре json.

Пока это магический Питон, который уже давно перестал быть просто языком, а стал набором заклинаний для библиотек, то модели хорошо работают. А стоит попросить что-то иное, скажем на старом, добром C (не плюсы) и уже начинаешь проверять каждую строку. Впрочем, если ставить просто алгоритмическую задачу - то он пишет ее. Хотя и здесь надо все проверять, т.к. он очень любит проводить тесты на фиктивных данных и радостно говорить, что все хорошо. Запускаешь свой тест и видишь иное.

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

Это и было сказано: рыночная заявка - это просто смещенная от текущей цены к границам текущего клиринга. Что не сказано в документации - изменение ГО при удалении от цены последнего клиринга. Чем дальше - тем больше.
Что приводит к неявному ответу от брокера о нехватке средств у любителей торговать на грани обеспечения. Нажимают кнопку в стакане "купить по рынку" - ответ: не хватает средств для покупки по цене (граница).
Вводишь руками цену, скажет на 100 пунктов от текущей - и магически уже денег хватает. Как же так - ошибка терминала, явно. Поэтому на срочном рынке нет заявок по рынку - есть ордера по указанной цене, и брокер проверит наличие средств именно для указанной цены, т.к. есть ненулевой шанс, что когда заявка дойдет до биржи, именно по этой цене она и исполнится.

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

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

В большинстве случаев этого, будет достаточно. Но не забывайте про ситуации, когда торги идут у границ.

Это Вам решать, понимая, что чем дальше цена, тем больше ГО. ГО по факту будет по цене исполнения, но брокер проверит наличие средств именно по цене ордера.
Ну и учитывая ликивдность инструмента, для кого-то отступ 100 шагов - достаточно, а для другого 500 и более.

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

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

На срочной секции нет рыночных ордеров. Можно только устанавливать ордера внутри ценовых границы последнего клиринга. Причина проста - сумма ГО зависит от цены.
Поэтому устанавливая ордер далеко от цены клиринга, ГО возрастает и существенно.

Вывел скриптом, используя метод AddLabel, указав путь к файлу с расширением png

Большая просьба не исправлять данное поведение, т.к. оно как раз ожидаемо в 2025 году.

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

Случайно вывел картинку в метку в формате png и она вывелась. Что-то изменилось в последних версиях? Раннее, да и сейчас руками на график, только bmp.

В теории да, раз в секунду. Но в реальности оно может изменяться порциями. Может стоять на месте, а потом разом на 10 секунд измениться. Т.е. это явно не про точность, а просто некая отметка времени для ориентира.

Опыт показывает, что визуальная ерунда усложняет продукт как в плане кодовой базы, так и в плане поддержки. Для работы нужен надежный, простой инструмент, а не средство для услады глаз.
В моем понимании такого рода продукты должны реализовываться модульно. Блок базовой функциональности - простой, надежный быстрый. Это ядро системы. К нему есть внутренний API.
Также есть блок визуализации информации. Простой и быстрый для тех, кому не нужны графики. И новомодный, хоть в web, чтобы прямо с КПК смотреть и радоваться. И пусть пользователи покупают то, что им надо.
При таком подходе если разработчики "красоты нечеловеческой" внесут ошибку, пожирающие ресурсы, то они не сломают ядро системы, которое продолжит исправно работать.
Сейчас же в угоду поколения смартфонов ломают то, что не должно ломаться ни в каком случае.

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

Да, я перепутал с флагом для shutdown. Надо попробовать.

И сравнивать изделия для созерцания наскальных графиков, читай TW, с средством быстрой доставки команд и данных - очень некорректно. Одно для масс, уткнувшихся в мизерный экранчик через "всёпожирающий" браузер, другой для организации потока данных и обработки команд. У Квика нет задачи стать WEB, удобным для графиков, красивых интерфейсов и прочая. Назвать удобным Quik сложно, но задачу он свою решает. Я бы наоборот выкинул лишнее и сделал более открытым внутренний API. А кому надо рисовать картинки, красивые кнопочки, AI, настройка цветов - да, стоит выбирать брокеров с web терминалами.

Я попросил бы The Bat не сравнивать с Quik. До сих пор на паре рабочих мест используется.

У меня итак 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 (если необходимо фильтровать) или просто пройдя по всем строкам, если без фильтра.
Можно даже не ждать, а просто организовать проверку числа записей и если оно увеличилось, то считать весь пришедший блок за раз.