возможна ли ситуация с получением данных графика, когда свеча уже имеется (учтена в getnumcandles), но ее значение не заполнено и по getCandlesByIndex возвращаются ohlcv 0?
возникает при очень частом опросе графика, последующий запрос выдает то же количество свечей, но ohlcv уже реальные
Максим написал: Здравствуйте, подскажите, есть ли возможность получение значений индикатора МАСД не открывая сам график и не рассчитывая самому в скрипте. Постановка задачи: Пройтись по таблице текущие торги и отобрать акции с определенным значением МАСД.
Egor Zaytsev написал: Какие еще условия вы бы хотели задавать
Здравствуйте, я бы хотел для одного инструмента задать одновременно отрицательное значение и положительное, к примеру -30% и +30%, и к сожалению нельзя выбрать применить такое условие ко всем активам в таблице, т.к нудно к примеру 258 акций вручную проставлять
Меssage выводит только строки. Остальные типы данных игнорирует. Поэтому вам нужно самим делать преобразование tostring явно или косвенно, как в вашем примере
я надеюсь, что Сергей Горохов или кто то другой из разработчиков сможет привести какой нибудь вразумительный рецепт, в какой момент робот может быть уверен, что полученные им последние, самые правые значения котировок на графике на самом деле отражают текущее состояние торгов, а не являются мусором, оставшимися из прошлых дней.
вопрос в том и состоит, как убедиться, что данные более менее актуальны и заветное пересечение скользящих средних на самом деле только что произошло, а не позавчера ))
то же самое относится и к иным данным, не только к истории котировок.
Я надеюсь, что разработчиков получится дать более-менее развернутый ответ.
вот и приведите эту последовательность. Или последовательности.
только желательно в общем виде. Я пытался многими способами и все равно время от времени получаю от людей, которые пользуются моими роботами логи, в которых видны невообразимые чудеса в вопросе получаемых роботами данных.
добавляя в терминал язык луа, вы наверняка подразумевали , что на нем будут писаться разные роботы и прочая торгующая ерунда.
в таком случае у вас должно быть понимание, как необходимо при помощи языка луа принимать решение о возможности начала работы алгоритма после старта скрипта.
проблема состоит в проверке, что данные, получаемые роботом из терминала, отражают текущее или почти текущее состояние торгов и можно приступать к анализу условий и самой торговле.
варианты:
1. Терминал давно запущен до запуска робота 2. Терминал и робот запущены одновременно , необходимые данные в терминале доступны 3. Терминал и робот запущены одновременно , необходимые данные в терминале пока недоступны 4. Смена сессии , нужные шлюзы доступны/недоступны, когда нибудь подключатся 5. У косого брокера на букву Ф опять понос и посреди дня он медленно и печально начал перезагружать всю историю с 1812 года 6. Инструмент неликвидный, много пропущенных свечей, в том числе последних
и так далее..
в общих словах вопрос.
как робот может понять, что данные, ему даёт терминал, являются более-менее актуальными, а не прошлогодними и можно торговать? Пожалуйста, приведите какую нибудь осмысленную последовательность проверок.
я понимаю, что терминал сам не знает, последняя свеча ему пришла или непоследняя. Но луа в терминал вы же не по пьяни встраивали, а после "регистрации пожелания, постараемся его рассмотреть и сообщить" и далее по тексту.
вы же пробовали сами что то писать на луа, верно?)
Сделайте скриншот таблицы обезличенных сделок, чтобы на нем было видно, что сделка с меньшим временем находится ниже сделки с бОльшим временем в пределах одного инструмента.
если такой случай сделать не получается (так и будет) - ищите ошибку в том, что у вас работает через "луа апи"
Александр написал: 1. В потоке обезличенных сделок: GAZP, BRV, SBER, RIZ0, SIZ0. 2. Создаю таблицу "Всех сделок" добавляю GAZP. 3. Жду загрузки 4. Удаляют из таблиц всех сделок, удаляю GAZP и добавляю BRV0 5. Жду когда загрузятся тики 6. Запускаю скрипт и получаю доступ к таблице all_trades через lua api. 7. Сначала выводятся сделки по BRV0 со временем 10:25 8. Потом идут сделки по BRV0 со временем 10:00 Получается в таблице all_trades - теряется порядок хронологии. Все остальные сделки идут верно.
никто и никогда не обещал, что в таблице обезличенных сделок будет какое то упорядочивание по времени.
единственное, на что можно полагаться с большой долей уверенности - что в пределах одного инструмента сделки будут отсортированы по возрастанию времени.
s_mike@rambler.ru написал: в getinfo по функции иногда не фигурирует ее название
По ссылке выше как раз ответ, если функция вызвана через pcall, дебаггер ее имя не найдет. От себя добавлю, что в квике все колбеки вызываются через pcall, инфа сотка.
то есть я не смогу получить ни одно название функции, вызванной в колбеке или предопределенной функции индикатора?
это утверждение опровергается практикой. Инфа сотка стопудово )
Антон, tail call обязательно фигурирует в списке вложенности. Вы это можете легко проверить.
речь идёт не о стеке вызовов, тут все правильно. Речь идёт о том, что в getinfo по функции иногда не фигурирует ее название. Хотя вся остальная информация верна, трассировка вызовов правильная.
в предыдущих версиях терминала я этого ни разу не замечал, хотя пользуюсь этим механизмом для отладки много лет. В 8.7 тоже было все нормально , а вот в 8.8 - нате вам.
может, причуды галактической пыли, может, у меня резкость пропала, а может и нога попала в колесо у разработчиков.
Anton написал: Предположу, что в одних местах функция вызвана "посередине", а в других происходит tail call, в этом случае уровень 1 заглядывает на функцию выше и, соответственно, локальных имен вызывающей функции не видит.
ничего не понял. Посередине - это как? Между левой и правой штаниной?))
Evgenii написал: Не думаю. Там несколько функций открытия сделок и отслеживание для выставления стоп заявок в цикле в течении бара. Плюс поля статусы. В теории даже названия моно переопределить, если уж совсем заморочиться. Но это не нужно. Реально используется очень мало. Речь не идет об кубиках Tslab
Спорить о вкусе ананаса имеет смысл только с тем, кто его пробовал.
s_mike@rambler.ru написал: скринсейвер с паролем решают проблему.
К сожалению не решают, а пользователю затрудняют жизнь. У меня сложный пароль а при входе через RDP буфер обмена не работает (может конечно это можно решить, я не искал) и приходится вводить вручную.
microsoft RDP клиент позволяет сохранить пароли и остальные настройки, они будут применяться автоматически.
Игорь написал: Можно высказать пожелание установить пароль на рабочее место Квика - чтобы ничего нельзя было сделать, но в то же время роботы, архивы все работало?
Сергей написал: Раз уж топик про снятие заявок, внесу и свои 5 копеек. Проблем с коллбэками onTransReply не наблюдал, но зато стабильно приходят два коллбэка onOrder, причем флаг снятия ордера поднят только во втором. Получается сначала приходит коллбэк о том, что мы якобы выставили ордер (хотя он уже есть и активен), и только потом, что он снимается. Зачем такая история? Терминал 8.3.2.4, если что.
Сначала в заявке изменяются некоторые поля, к которым у вас доступа нет и вы не видите изменений в первом пришедшем колбеке, потом заявка снимается и снова вам приходит колбек, в котором изменения вам уже видны.
s_mike@rambler.ru написал: Позволено в скриптах, отказано в индикаторах
Эти константы используются в CreateDataSource, который недоступен в индикаторах.
То, что они недоступны, козе известно.
Оказывается, что константы таймфреймов у createdatasource getsourceinfo совпадают частично, а не полностью. Все таймфреймы от тикового до H4 включительно имеют одинаковые значения, а D1,W1,MN1 разные.
Вот это номер.
Была такая игра - Prince of Persian, где героя на каждом шагу ожидали неожиданные и нелогичные засады. Только там они были сделаны намеренно....
Sergey Gorokhov написал: s_mike@rambler.ru, Просто в тексте ошибки забыли поменять старое наименование. Правильно так "CreateDataSource failed" Текст обязательно поправим.
ясно, Сергей.
Вообще то диагностика createdatasource failed не несёт в себе ни байта полезной информации. "Чтой-та гдета нитаво". Это мы и так знаем, раз полезли смотреть диагностику ошибки.
если уж полезете исправлять, надо бы что то более осмысленное возвращать.
Anton написал: Линейная у SearchItems сложность. Искал в ТВС. Оси условные.
Да, тоже посмотрел, линейная. Утверждение, что SearchItems работает быстрее, стало еще более загадочно, с чего бы?
Цикл перебора по getitem гоняет ВСЕ данные через бутылочное горлышко между скриптом и терминалом. На этом много потерь.
SearchItems при наличии фильтрации прореживает данные хранилища внутри qlua и выдает на гора уже выборку. За счет этого идет значительная экономия при правильно выбранных фильтрах.
Nikolay написал: Собирали сами? У меня стабильно падала после некоторого времени. Надо заново проверить, вдруг починили. Техподдержка Квика так и не ответила, по моему обращению.
да, сам собрал.
если надо, пишите почтой, поделюсь.
если вдруг у кого то есть sqlite для 5.3 x64 - буду очень рад.
function SQL_Rows (connection, sql_statement)
local cursor = assert(connection:execute (sql_statement))
return function ()
return cursor:fetch()
end
end
Кстати, у Вас библиотека на х64 стабильно работает? Я бросил попытки еще в январе.
Евгений написал: Собственно вопрос. Как это работает? При сдвижке одного индикатора что происходит с остальными? И какие значения возвращаются в таблице? Вопрос возник при расчете сигналов по закрытой свече или по текущей..Если сдвинут один индикатор вперед на 1, который даже не используется в этом скрипте то остальные то на самом деле сдвигаются остальные назад на 1 ? или как?
добавляется ещё одна свеча справа. Нумерация свечей не изменяется. У несдвигутых вправо индикаторов значения будут nil