Особенности работы индикатора при вызове из эксперта
плохо. есть подводный камень. если нет обращения более 5 минут, то данные будут выгружены и будут недоступны
плохо. есть подводный камень. если нет обращения более 5 минут, то данные будут выгружены и будут недоступны
Обычные рабочие индикаторы теперь имеют увеличенный таймаут выгрузки в 30 минут вместо 1 минуты. В тестере выгрузка рабочих индикаторов не производится вовсе.
плохо. есть подводный камень. если нет обращения более 5 минут, то данные будут выгружены и будут недоступны
Слегка взяглянул, наверно надо придерживаться принципа обновления данных не реже, чем раз на бар. Если берете данные с другого таймфрема, то этот другой тамфрейм надо обновлять в соответствующей ему перодичности, а когда брать с него данные для вычисления - это другой вопрос.
Да, фоновой просчет индикаторов (особенно кастомных) в тестере занимает существенные(почти все) ресурсы.
Причин несколько:
- Просчет тестером загруженных индикаторов всегда даже если его результаты не нужны
Решением может быть автоматический перерасчет по требованию. Если индикатор вызывается редко, то он перерасчитывается только в моменты обращения к нему. Это может ускорить расчеты в разы. - Неэкономные индикаторы
Тут надо писать экономичные индикаторы. - Еще не включена полная оптимизация MQL5 кода
На днях мы выпускаем бету 64-битного терминала с полной поддержкой нативного x64 исполнения MQL5 кода. После тестирования начнем включать ранее отключенные механизмы оптимизатора, что даст серьезный (десятки и сотни процентов) прирост скорости.
В последнем 291 билде был уже улучшен механизм перерасчета индикаторов в режимах OHLC и по ценам открытия - индикаторы стали считаться только в момент вызова эксперта, что ускорило расчеты. Раньше в этих режимах индикаторы все равно считались потиково.
В последнем 291 билде был уже улучшен механизм перерасчета индикаторов в режимах OHLC и по ценам открытия - индикаторы стали считаться только в момент вызова эксперта, что ускорило расчеты. Раньше в этих режимах индикаторы все равно считались потиково.
У меня один из экспертов, использующий несколько индикаторов, престал оптимизироваться. Результат возвращает только первый прогон, последующие прогоны: returned result 0.00
У меня один из экспертов, использующий несколько индикаторов, престал оптимизироваться. Результат возвращает только первый прогон, последующие прогоны: returned result 0.00
Представьте, пожалуйста, больше информации чтобы мы смогли смоделировать и проверить ситуацию.
Лучше всего это сделать из своего профайла через штатную функцию сервисдеска, поставив соответствующий тикет с приаттаченными файлами напрямую разработчикам.
У меня один из экспертов, использующий несколько индикаторов, престал оптимизироваться. Результат возвращает только первый прогон, последующие прогоны: returned result 0.00
Я тоже столкнулся с такой же проблемой. У меня нулевые результаты оптимизации всегда появлялись после ошибки в эксперте при каком-то прогоне. Наиболее распространённой ошибкой является вызов элемента массива за пределами его размера. Причём в моем случае нулевые результаты сохранялись после перехода оптимизации от "плохих" входах к "хорошим". Я сделал простой пример эксперта чтобы показать как нулевые результаты оптимизации возникают после первой ошибки в прогоне и сохраняются несмотря на то что в последующих прогонах ошибок нет. Но оптимизация этого упрощённого эксперта работала как нужно, с нулевыми прогонами только в тех случаях где возникает ошибка. Так что я закрыл эту заявку в сервисдеске.
Ради интереса, возьмите входные данные Вашего последнего прогона с ненулевыми результатами и первого нулевого прогона и прогоните Ваш эксперт с этими вхдоами с отключенной оптимизацией чтобы убедиться что нет ошибок.
Я тоже столкнулся с такой же проблемой. У меня нулевые результаты оптимизации всегда появлялись после ошибки в эксперте при каком-то прогоне. Наиболее распространённой ошибкой является вызов элемента массива за пределами его размера. Причём в моем случае нулевые результаты сохранялись после перехода оптимизации от "плохих" входах к "хорошим". Я сделал простой пример эксперта чтобы показать как нулевые результаты оптимизации возникают после первой ошибки в прогоне и сохраняются несмотря на то что в последующих прогонах ошибок нет. Но оптимизация этого упрощённого эксперта работала как нужно, с нулевыми прогонами только в тех случаях где возникает ошибка. Так что я закрыл эту заявку в сервисдеске.
Ради интереса, возьмите входные данные Вашего последнего прогона с ненулевыми результатами и первого нулевого прогона и прогоните Ваш эксперт с этими вхдоами с отключенной оптимизацией чтобы убедиться что нет ошибок.
У меня один из экспертов, использующий несколько индикаторов, престал оптимизироваться. Результат возвращает только первый прогон, последующие прогоны: returned result 0.00
Индикаторы оказались не при чем. AccountInfoString(ACCOUNT_SERVER) - возвращает при первом прогоне оптимизации "MetaQuotes-Demo", при последующих ""(пусто).
Индикаторы оказались не при чем. AccountInfoString(ACCOUNT_SERVER) - возвращает при первом прогоне оптимизации "MetaQuotes-Demo", при последующих ""(пусто).
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Тестируем по всем тикам. Индикатор где-то там, куда-то загружен, живет своей жизнью, вычисление индикатора выполняется на каждом тике. Пусть даже индикатор написан правильно и на новом тике расчеты выполняются только для одного бара.
В экспертах бывает два типа функций: которые должны выполняться на каждом тике, и те, выполнения которых достаточно раз на бар. Ко вторым, выполняющимся раз на бар, чаще всего относятся функции связанные с индикаторами. В МТ4 было просто ограничить количество вызовов индикатора до одного раза на бар, а здесь индикаторы живут своей жизнью. Получается, что все индикаторы надо дорабатывать, делать параметр, указывающий, что индикатор должен вычисляться только один раз на бар.
Было бы неплохо устанавливать индикатору свойство из эксперта - вычислять ли его на каждом тике или раз на бар. Что-то типа IndicatorSetProperty(Handle, ONCE_ON_BAR)