Оптимизация первоначального расчета индикатора - страница 3

Ага... Пока писал, кольнула одна мысль, отвлекся. Спасибо, поправил.

Согласен на все 200%. Это абсолютно логичное решение. Дело советника - получить сигнал и на его основании либо войти в рынок, либо выйти. Сигнал, в любом случае,  формируется на основании показаний индикаторов (не важно, встроенный или внешний). И какой смысл тащить данные в эксперт и тратить ресурсы компа на тупую перекачку огромных массивов таймсерий?! Я уже не говорю о стат. обработке...

Я тут на досуге почитываю хелп к MQL5 и наткнулся на главу "Доступ к таймсериям и данным индикаторов", так вот среди представленных функций доступа к данным индикаторов все начинаются со слова COPY !! Если я в своей системе все буду COPY-ровать в эксперт и там обрабатывать - даже мой двух-ядерник умрет на "раз". Это еще раз меня убеждает в мысли, что всю обработку нужно делать в индикаторах, а в эксперт передавать только сигнал.

Правда есть тревожные признаки того, что разработчики МТ5 думают иначе (цитата из хелпа MQL5):

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

Согласен, что расчеты должны быть именно в индикаторах. При вызове их из эксперта достаточно ограничивать глубину расчета необходимой для работы логики эксперта величиной (естественно, не меньше, чем кол-во баров для валидности самого индюка). К примеру, если используется SMA, и для логики эксперта достаточно последнего и предыдущего значений, то глубина расчета = период SMA + 1.

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

Т.е. имеет смысл во внешней переменной History индикатора (глубина пересчета) предусмотреть такую логику:

=0 - пересчет по всей истории;

>0 - пересчет по заданному количеству;

< 0 или 1 - минимально необходимое кол-во баров для пересчета.

Последний вариант и использовать для вызова из эксперта.

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

Ничего подобного.

Чушь

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

Возвращаясь к оптимизации кода.

Предположим, в своем индикаторе вы используете (вызываете) др. индюк, у которого период = ф-я от, скажем, считаемой в вашем индикаторе волатильности.

Тогда при каждом изменении периода вызываемый индюк будет пересчитываться заново по всей истории, если явно не задать глубину его пересчета. Если же вызывается встроенный в МТ индикатор, то такой возможности нет вообще!

Эрго:

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

заменять кодом с возможностью установки глубины пересчета встроенные в МТ индикаторы;

опционально внедрять код вызываемого индикатора.

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

Еще раз. Это нужно ТОЛЬКО, если праметры вызываемого индикатора дин.меняются вызывающим индикатором. Если они статичны, то он пересчитываются полностью только при изменении истории, и на это можно забить.

Можете проэкспериментировать: сделайте индюк, где будет считать параболик с АФ, зависимым от АТР (с соответствующим масштабированием, ессно). Ждать, когда он просчитается, можно оччччень долго...)))

Если же параболика не вызывать, а внедрить его код, то задержки просто не заметите...