Time[0] во время смены таймфрейма - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Насколько я понял, асинхронно - в данном случае значит "беспорядочно". То есть порядок загрузки баров может не соответствовать упорядочению их времен открытия. И "все про это знают", только в официальном хелпе про это - ни слова (вроде бы).
Имеется в виду, что если в течение дня использовался таймфрейм Н1 и переключение на другие таймфреймы не происходило, то истории по другим таймфреймам и нет. В момент переключения ТФ загрузка данных по нужному ТФ только начинается. Просто при современной скорости Интернет пользователь этого практически не замечает.
Ещё раз спасибо, ERR_HISTORY_WILL_UPDATED - полезна. При этом с помощью этого кода ошибки проверяется загрузка всей истории - несмотря на то , что для индикатора нужны например самые поздние 100 баров. Приходится ждать несколько секунд, вместо того, чтобы сразу начать оперировать со 100 барами. Но нет, они могут еще измениться в процессе подгрузки. Правильно?
К сожалению, узнать, загрузились ли нужные нам бары, нет возможности. Либо вся доступная история (в зависимости от настроек терминала), либо не вся.
Еще вопрос и заранее еще большее спасибо - в чём разница между iTime(NULL,0,0) и iTime(NULL, i_tf,0) если i_tf соответствует текущему таймфрейму? По идее никакой (если верить официальному хелпу). Кроме того, если определять i_tf руками, то пропадает смысл переключения таймфремов в терминале - программа просто будет работать на текущем таймфрейме и всё.
Разницы никакой. Дело лишь за тем, как поставлена задача. Если нужно работать на текущем таймфрейме, то функции "i" (iOpen, iTime и т. д.) не нужны. В таком случае за правильностью расчета данных индикатора должна следить другая функция, отслеживающая изменения в истории. Всего случаев, с которыми должна сталкиваться такая функция, три:
1. Начальная работа индикатора. Нужно рассчитать данные на всех доступных барах. В этом случае параметр prev_calculated в функции OnCalculate будет иметь значение 0. Что делать: последовательный расчет данных всех баров в истории.
2. Работа индикатора в режиме обновления без подкачек истории (приход нового тика). Переменная prev_calculated равна rates_total (пришел тик в текущем баре) или меньшее ее на 1 (образовался новый бар). Что делать: разность 0 - пересчитать бар с индексом 0, разность 1 - пересчитать бары с индексами 1 и 0.
3. Работа индикатора в случае подкачки истории. Такое бывает, например, если индикатор работал, затем на время пропала связь, а потом появилась. В итоге количество баров на графике может измениться более, чем на 1 бар. Соответственно значение prev_calculated будет меньше значения rates_total на 2 и более бара. Что делать: можно пересчитать измененные бары (начиная с бара rates_total - prevcalculated), но лучше, для верности (да и универсальнее), пересчитать всю историю.
Насколько я понял, асинхронно - в данном случае значит "беспорядочно". То есть порядок загрузки баров может не соответствовать упорядочению их времен открытия. И "все про это знают", только в официальном хелпе про это - ни слова (вроде бы).
Ещё раз спасибо, ERR_HISTORY_WILL_UPDATED - полезна. При этом с помощью этого кода ошибки проверяется загрузка всей истории - несмотря на то , что для индикатора нужны например самые поздние 100 баров. Приходится ждать несколько секунд, вместо того, чтобы сразу начать оперировать со 100 барами. Но нет, они могут еще измениться в процессе подгрузки. Правильно?
Еще вопрос и заранее еще большее спасибо - в чём разница между iTime(NULL,0,0) и iTime(NULL, i_tf,0) если i_tf соответствует текущему таймфрейму? По идее никакой (если верить официальному хелпу). Кроме того, если определять i_tf руками, то пропадает смысл переключения таймфремов в терминале - программа просто будет работать на текущем таймфрейме и всё.
Мой советник берёт данные с 5-ти ТФ, потому открыты всегда 5 графиков, чтобы всегда были котировкм, а смотрю на 1 график, на котором установлен советник. Сделайте так, и всё будет в ажуре!
Мой советник берёт данные с 5-ти ТФ, потому открыты всегда 5 графиков, чтобы всегда были котировкм, а смотрю на 1 график, на котором установлен советник. Сделайте так, и всё будет в ажуре!
Да, это выход. Но если программа пишется для другого пользователя или группы трейдеров, то всех их не заставишь делать подобные костыли. Потому и речь о том, чтобы все проблемы, которые возможно решить программно, программа решала сама.
Да, это выход. Но если программа пишется для другого пользователя или группы трейдеров, то всех их не заставишь делать подобные костыли. Потому и речь о том, чтобы все проблемы, которые возможно решить программно, программа решала сама.
Вы правы, что всё возможно делать программно! Но реальность требует быстрого реагирования на повадки рынка (или тех, кто им правит)! Потому легче что-то во-время подправить в более простом коде, чем в сложном. И всё равно на все случаи наперёд всего не напишешь! Давно уже не пользуюсь кодами других и свой никому не предлагаю, т.к. ненадёжно, не то и не другое. А сам я всегда у себя под боком! ;))
Имеется в виду, что если в течение дня использовался таймфрейм Н1 и переключение на другие таймфреймы не происходило, то истории по другим таймфреймам и нет. В момент переключения ТФ загрузка данных по нужному ТФ только начинается. Просто при современной скорости Интернет пользователь этого практически не замечает.
К сожалению, узнать, загрузились ли нужные нам бары, нет возможности. Либо вся доступная история (в зависимости от настроек терминала), либо не вся.
Разницы никакой. Дело лишь за тем, как поставлена задача. Если нужно работать на текущем таймфрейме, то функции "i" (iOpen, iTime и т. д.) не нужны. В таком случае за правильностью расчета данных индикатора должна следить другая функция, отслеживающая изменения в истории. Всего случаев, с которыми должна сталкиваться такая функция, три:
1. Начальная работа индикатора. Нужно рассчитать данные на всех доступных барах. В этом случае параметр prev_calculated в функции OnCalculate будет иметь значение 0. Что делать: последовательный расчет данных всех баров в истории.
2. Работа индикатора в режиме обновления без подкачек истории (приход нового тика). Переменная prev_calculated равна rates_total (пришел тик в текущем баре) или меньшее ее на 1 (образовался новый бар). Что делать: разность 0 - пересчитать бар с индексом 0, разность 1 - пересчитать бары с индексами 1 и 0.
3. Работа индикатора в случае подкачки истории. Такое бывает, например, если индикатор работал, затем на время пропала связь, а потом появилась. В итоге количество баров на графике может измениться более, чем на 1 бар. Соответственно значение prev_calculated будет меньше значения rates_total на 2 и более бара. Что делать: можно пересчитать измененные бары (начиная с бара rates_total - prevcalculated), но лучше, для верности (да и универсальнее), пересчитать всю историю.
Благодарю за подробные разъяснения!
Имеется в виду, что если в течение дня использовался таймфрейм Н1 и переключение на другие таймфреймы не происходило, то истории по другим таймфреймам и нет. В момент переключения ТФ загрузка данных по нужному ТФ только начинается. Просто при современной скорости Интернет пользователь этого практически не замечает.
Если для советника нужна мультитаймфреймовая история, то достаточно на график повесить мультитаймфреймовый индикатор, и история будет подкачиваться сразу по всем таймфреймам.
А если пользователь об этом не знает?
Костылей выдумать можно много. Правильный же путь - предусмотреть такую ошибку во время выполнения программы. Тем более в данном случае это не так уж и сложно.
Кстати, есть еще один способ автоматического обновления нужного таймфрейма: обращаться к нему на каждом тике путем использования любой функции "i".
А если пользователь об этом не знает?
Костылей выдумать можно много. Правильный же путь - предусмотреть такую ошибку во время выполнения программы. Тем более в данном случае это не так уж и сложно.
Кстати, есть еще один способ автоматического обновления нужного таймфрейма: обращаться к нему на каждом тике путем использования любой функции "i".
Конечно, эту заботу можно перенести из индикатора в советник. НО есть существенная разница в быстродействии: индикатор выполняется в отдельном потоке, а советник при этом будет производить "лишние" вычисления.
НО есть существенная разница в быстродействии: индикатор выполняется в отдельном потоке, а советник при этом будет производить "лишние" вычисления.
Мы, конечно, уклоняемся от темы, но, тем не менее, замечу, что как раз быстродействие абсолютно не страдает.
Во-первых, индикатор в МТ4 исполняется не в отдельном потоке (своем), а в интерфейсном потоке терминала (в то время как эксперт не занимает какой-либо "чужой" поток), что уже увеличивает нагрузку на интерфейсный поток, иногда мешая пользователю в работе с мышью и клавиатурой. Но даже не в этом дело, т. к....
Во-вторых, для инициализации начала загрузки данных по нужному символу/таймфрейму как индикатор, так и советник, должны вызвать одну и ту же функцию:
или ей подобную (iOpen, iClose, iHigh, iLow, iVolume). Скорость выполнения этой функции одинакова для любой программы, и не думаю, что работа такой функции занимает слишком много времени. Скорее всего, мизер.
В-третьих, закачка данных происходит не в потоке вызывающей программы, а в том потоке, который выделен самим терминалом для этих нужд (какой именно - не знаю).
Таким образом, индикатор, который запущен только с целью поддержки актуальности данных нужных таймфреймов, не способен не то чтобы кардинально, а в принципе, увеличить быстродействие системы. Замедлить - возможно, но это очень тяжело измерить.
Получаем, что разница в методах поддержки актуальности данных заключается в количестве программ, необходимых для выполнения поставленной задачи. Чем меньше программ, тем меньше кликов для их запуска. То есть вариант "все в одном флаконе" в данном случае более предпочтителен.
Мы, конечно, уклоняемся от темы, но, тем не менее, замечу, что как раз быстродействие абсолютно не страдает.
Во-первых, индикатор в МТ4 исполняется не в отдельном потоке (своем), а в интерфейсном потоке терминала (в то время как эксперт не занимает какой-либо "чужой" поток), что уже увеличивает нагрузку на интерфейсный поток, иногда мешая пользователю в работе с мышью и клавиатурой. Но даже не в этом дело, т. к....
Во-вторых, для инициализации начала загрузки данных по нужному символу/таймфрейму как индикатор, так и советник, должны вызвать одну и ту же функцию:
или ей подобную (iOpen, iClose, iHigh, iLow, iVolume). Скорость выполнения этой функции одинакова для любой программы, и не думаю, что работа такой функции занимает слишком много времени. Скорее всего, мизер.
В-третьих, закачка данных происходит не в потоке вызывающей программы, а в том потоке, который выделен самим терминалом для этих нужд (какой именно - не знаю).
Таким образом, индикатор, который запущен только с целью поддержки актуальности данных нужных таймфреймов, не способен не то чтобы кардинально, а в принципе, увеличить быстродействие системы. Замедлить - возможно, но это очень тяжело измерить.
Получаем, что разница в методах поддержки актуальности данных заключается в количестве программ, необходимых для выполнения поставленной задачи. Чем меньше программ, тем меньше кликов для их запуска. То есть вариант "все в одном флаконе" в данном случае более предпочтителен.