s_mike@rambler.ru (Все сообщения пользователя)

Скрипт большой, чтобы его выложить.

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


никаких сортировок чего+то подобного в скрипте нет.

Господа-разработчики также как и я в растерянности?)

Задача. Хорошо,у вывести содержимое ТОС по классу TQBR в файл.

последовательность моих действий в скрипте:

1. Спрашиваю состав бумаг класса
2. Делаю подписку на каждую бумагу на тиковом диапазоне.
3. Периодически читаю ТОС на предмет новых сделок через SearchTable. Все полученное пишу последовательно в файл.

я хочу получить отсортированную по времени ТОС последовательность сделок в файле.

не тут-то было...

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

что я получаю в файле (скрипт запущен после окончания торгового дня)

1. Сначала идёт полный список сделок с 10-00 по 18-45 по Газпрому
2. Далее вперемешку сделки ЛУКойла и сбербанка, тоже полный день с 10-00 до 18-45
3. И только после этого идут сделки по всем остальным инструментам в правильной последовательности в соответствии со временем.

я догадываюсь, что дело в наличии или отсутствии сделок по разным инструментам в хранилище терминала

однако хотелось бы понять:
1. Чем Газпром отличается от ЛУКойла со сбером
2. Как выводить сделки в файл в правильной последовательности в соответствии со временем.
3. Можно ли решить задачу полностью из луа без беганья с бубном по всевозможным настройкам в терминале?

Спасибо.

В луа (github) есть библиотеки для работы с http. Подключайте их и читайте страницы.
Дело муторное.

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

проверка длины таблицы на каждой обезличенной сделке не бомбит терминал? А если инструментов в ТОС много или очень много?

ну конечно.... Попробуйте то что вы написали в действии.

в общем случае нельзя

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

В окне заказа обезличенных сделок есть кнопка "получить заново".

можно ли отследить нажатие этой кнопки из луа?

спасибо.

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

в этом случае польза от градиентов есть.


В вашем случае как применять эти градиенты -непонятно. Ну разве что для галочки - в терминале есть градиенты!

а чему тут удивляться? Идёт вызов колбека и внутри него вы разрушаете его контекст. Конечно нельзя.

использование команды format c: /y внутри командного файла windows тоже приведет к проблеме с дальнейшим выполнением команд из этого командного файла. Правда в последних версиях windows система откажется от суицида )

Они не тестируют.

Вы тестируете. Бесплатно.

хорошая экономия на персонале.

только нужно помнить, что getlabelparam - кривой как весь верблюд букву Q.

getlabelparams будет возвращать координаты метки ещё в процессе переноса.

то есть нацелились на метку зажали кнопку мыши и двигаем метку. вы еще целитесь, куда метку передвинуть, а getlabelpatams уже возвращает новые координаты.  

это плохой совет. Выйти по тейк-профиту с убытком легко.

вы невнимательно читали. Скорость достигается за счёт inline кода, а вы опять функции пишете.

Обновил статью - добавил пример проверки бита, отличного от младшего

Вот, например, на ту же тему: Особенность интерпретатора Lua но уже внутри самого интерпретатора

В луа нет целых 32-разрядных целых. Там есть только float

print(0xFFFFFFFF)   --> 4294967295

Положительное число.

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

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

Михаил Понамаренко

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

Поэтому в одних условиях ваш индикатор будет строиться правильно, в других случаях у вас будут нули.

Способа заставить рассчитываться индикаторы в нужной нам последовательности нет (не предоставлено, да и невозможно)

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

Сигналом к такому перерасчету может быть (в частности) приход первого тика в ваш индикатор после первичного расчета. Тик придет уже после расчета всех индикаторов, в том числе и нужного вам. Этот сигнал будет при построении индикатора во врея торгов. Если торгов нет или нет соединения с брокером - изобретайте сигнал к пересчету сами.

Вы просто не поняли суть проблемы. Если количество свечей на графике == 1, то все приходящие тики имеют номер свечи == 1 в случае продолжения торгов в пределах этой же свечи.

Подумайте.

Сергей. Вы совершенно неправильно меня понимаете.

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

Возвращаемся в примеру, когда на графике есть всего одна свеча.

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

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

Да, речь идет об отслеживании начала расчета.

Да, на свежих версиях колбек онкалкулате вызывается на пустых свечах. Первая причина снята.

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

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

Да и вообще. Такая проверка - самый натуралный официально признанный костыль.  

Отправил.

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

Способ сравнения номера свечи с 1 проблему не решает. Свеча  с номером 1 может быть пустой и колбек oncalculate на ней никогда не вызовется. Также ничто не мешает графику состоять просто из одной свечи - в этом случае " полный перерасчет" будет на каждом тике.

Всвязи с этим регистрируйте пожелание. Либо нужно ввести новый колбек либо добавить в вызов oncalculate еще один параметр true/false, отражающий надичие полного перерасчета графика.

Sergey Gorokhov

Одним словом, написал я этот прокси-модуль. встроил в несколько индикаторов (не слишком заумных) - все нормально.

Есть желание протестировать?

Обращайтесь, нарисую.

Для работы с индикаторами, конечно

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

если делать по уму -нужно писать прокси для всех функций работы с таблицами qlua. Которые будут отфильтровать пустые свечи, как будто их и нет

дело муторное и неблагодарное.

смогли бы?

Понятно.

таким образом, ваш принцип состоит из трех идей.

1. всегда рассчитываем свечи по порядку их следования
2. строим буфер исходных данных с фильтрацией пропусков
3. строим буфер рассчитанных данных с фильтрацией пропусков.


для простейших индикаторов подходит.

теперь берем что-то посложнее типа зигзага.   вопрос таков. необходимо изменить значение в свече с номером size()-k, где k есть вычисляемое значение.  как с этим будете бороться?  третий буфер вводить?

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

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

Ждем.

setvalue или setrangevalue чем-то не устраивают?

Неправильно

1. Пустой может быть первая свечка, предыдущей не существует

2. Может быть подряд несколько пропущенных свечей

3...... И так далее.

закрыть файл и использовать os.remove()

если речь идет о перерастет графиков (а именно об этом было выше в ветке), то утверждение о невозможности пересчета чаще 1 раза в секунду неверно.

такое ограничение есть у анализатора.

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

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

А пока разработчики думают, посмотрите вот это

отключите выскакивающее окно с сообщениями и оно перестанет вас раздражать

Цены типа 1152.31005859375 - это фикция. Их не бывает в реальности.

quik показывает реальные цифры. Цены на сделок всегда кратны шагу цены, установленному биржей для каждого инструмента. Для вашего инструмента она скорее всего определена в в 0.01

появление в wld или метатрейдере дополнительных разрядов - это самодеятельность.

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

поправят, говорите?

http://www.bot4sale.ru/blog-menu/qpile/qpile-errors.html

это лишь то, на что я натыкался сам.

обратите внимание на даты статей

При помощи библиотеки luacom

a=string.gsub()
nm=tonumber(a)

например, новые метаметоды, как следствие новые способы построения классов.

но что об этом говорить... Проверку на противоречивость это не пройдет в арке... Или правовые аспекты помешают танцевать )

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

или просто приготовьте денежку малую и вам все сделают.

Топикстартеру могу присоветовать взять готовое, если у него не стоит задача практиковаться в qlua

Juggler - индикатор вычисления любой мат формулы над двумя другими любыми графиками

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

Баба с возу - кобыла в курсе )

Я не могу быть в этом уверен, я не разработчик quik. Но эту закономерность замечал