Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Описка?
Ага... Пока писал, кольнула одна мысль, отвлекся. Спасибо, поправил.
Даже если описка, то очень даже правильная :), имхо.
Существует целый класс индикаторов, которые переносятся в советник с большими проблемами.
Для остальных время выполнения в подавляющем большинстве случаев некритично, поэтому в индюке держать логику удобней и проще.
Согласен на все 200%. Это абсолютно логичное решение. Дело советника - получить сигнал и на его основании либо войти в рынок, либо выйти. Сигнал, в любом случае, формируется на основании показаний индикаторов (не важно, встроенный или внешний). И какой смысл тащить данные в эксперт и тратить ресурсы компа на тупую перекачку огромных массивов таймсерий?! Я уже не говорю о стат. обработке...
Я тут на досуге почитываю хелп к MQL5 и наткнулся на главу "Доступ к таймсериям и данным индикаторов", так вот среди представленных функций доступа к данным индикаторов все начинаются со слова COPY !! Если я в своей системе все буду COPY-ровать в эксперт и там обрабатывать - даже мой двух-ядерник умрет на "раз". Это еще раз меня убеждает в мысли, что всю обработку нужно делать в индикаторах, а в эксперт передавать только сигнал.
Правда есть тревожные признаки того, что разработчики МТ5 думают иначе (цитата из хелпа MQL5):
нельзя использовать функции по работе с графическими объектами в пользовательских индикаторах
Согласен, что расчеты должны быть именно в индикаторах. При вызове их из эксперта достаточно ограничивать глубину расчета необходимой для работы логики эксперта величиной (естественно, не меньше, чем кол-во баров для валидности самого индюка). К примеру, если используется SMA, и для логики эксперта достаточно последнего и предыдущего значений, то глубина расчета = период SMA + 1.
Это реально важная тема, т.к. перерасчет в стандартной конструкции пересчета в индикаторе производится не только при пропущенных последних барах, но и при докачки истории "внутри" истории и "до" - логика работы IndicatorCounted(). Поэтому перерасчет будет не только при первом включении эксперта или при разрыве связи, а в процессе и иногда довольно часто. Ждать минуты на перерасчет всей истории глупо, надо ограничивать глубину именно этим валидным для индюка и эксперта периодом.
Т.е. имеет смысл во внешней переменной History индикатора (глубина пересчета) предусмотреть такую логику:
=0 - пересчет по всей истории;
>0 - пересчет по заданному количеству;
< 0 или 1 - минимально необходимое кол-во баров для пересчета.
Последний вариант и использовать для вызова из эксперта.
По моим скромным наблюдениям, перенос расчетов в советник имеет одно неоспоримое преимущество при некоторых стратегиях ( особенно, если они работают по сформировавшимся барам), сокращается время реакции советника на команду торговли. Т.е. после расчета и принятия решения к той или иной торговой операции, если расчет в советнике, то команда выполняется на том же тике, если расчет в индикаторе, то советник выполнит команду торговли как минимум на следующем тике, а если и советник, в силу логики стратегии, работает по ценам открытия, то только на следующем баре. И в том и в другом случае это может быть существенной (для торговой операции) задержкой.
Ничего подобного.
По моим скромным наблюдениям, перенос расчетов в советник имеет одно неоспоримое преимущество при некоторых стратегиях ( особенно, если они работают по сформировавшимся барам), сокращается время реакции советника на команду торговли. Т.е. после расчета и принятия решения к той или иной торговой операции, если расчет в советнике, то команда выполняется на том же тике, если расчет в индикаторе, то советник выполнит команду торговли как минимум на следующем тике, а если и советник, в силу логики стратегии, работает по ценам открытия, то только на следующем баре. И в том и в другом случае это может быть существенной (для торговой операции) задержкой.
Чушь
По моим скромным наблюдениям, перенос расчетов в советник имеет одно неоспоримое преимущество при некоторых стратегиях ( особенно, если они работают по сформировавшимся барам), сокращается время реакции советника на команду торговли. Т.е. после расчета и принятия решения к той или иной торговой операции, если расчет в советнике, то команда выполняется на том же тике, если расчет в индикаторе, то советник выполнит команду торговли как минимум на следующем тике, а если и советник, в силу логики стратегии, работает по ценам открытия, то только на следующем баре. И в том и в другом случае это может быть существенной (для торговой операции) задержкой.
По моим скромным наблюдениям, разница в скорости между корректно написанным и корректно же используемым (см.мои посты выше) индикатором некритична для работы советника. Исключением м.б. ситуация, когда вы из советника динамично меняете параметры вызваемого индикатора. Тогда все становится значительно медленнее и лучше внедрить (и то только для ускорения оптимизации). Но это вообще общий подход - касается также создания пользовательских индикаторов, где используется вызов др.индикаторов с динамическими параметрами. В этом случае также лучше внедрить код.
Возвращаясь к оптимизации кода.
Предположим, в своем индикаторе вы используете (вызываете) др. индюк, у которого период = ф-я от, скажем, считаемой в вашем индикаторе волатильности.
Тогда при каждом изменении периода вызываемый индюк будет пересчитываться заново по всей истории, если явно не задать глубину его пересчета. Если же вызывается встроенный в МТ индикатор, то такой возможности нет вообще!
Эрго:
при вызове польз.индикаторов надо передавать ему параметр для его минимально возможного пересчета (соответственно, предусмотреть такой параметр и алгоритм в самом вызываемом индикаторе);
заменять кодом с возможностью установки глубины пересчета встроенные в МТ индикаторы;
опционально внедрять код вызываемого индикатора.
Последнее ну совсем уж опционально!))) Большинство индикаторов имеют пропорциональную зависимость минимальной глубины пересчета к его параметрам. А вот параболик, например, нет. Его лучше внедрять.
Еще раз. Это нужно ТОЛЬКО, если праметры вызываемого индикатора дин.меняются вызывающим индикатором. Если они статичны, то он пересчитываются полностью только при изменении истории, и на это можно забить.
Можете проэкспериментировать: сделайте индюк, где будет считать параболик с АФ, зависимым от АТР (с соответствующим масштабированием, ессно). Ждать, когда он просчитается, можно оччччень долго...)))
Если же параболика не вызывать, а внедрить его код, то задержки просто не заметите...