Как отключить Лог-файл при тестировании и оптимизации ? - страница 6

Новый комментарий
 
Есть только 2 варианта торможения : либо индикатор часто пересчитывается, либо долгое обращение к истории и соответственно долгий вызов функции start()

Ни то, ни другое. Я же говорю, что слишком часто вызывается индикатор с полным пересчётом! И дело не в индикаторе, а в эксперте, который вызывает этот индикатор через раз
 
Объясните подробнее, что значит "два-три бара пропустили без расчёта, получите полный пересчёт".
В советнике часто бывает ситуация, когда если есть ордера, то индикатор не вызывается и бар пропускается дальше.

В своё время я эмпирически обнаружил, что попытка сэкономить за счёт 
if (какое-нибудь условие) MyInd = iCustom(...)

вместо "тупого" 

int start() {
  MyInd = iCustom(...)

, даёт обратный эффект, и весьма сильный. Пост Slawa 26.04.07 15:48 проясняет эффект. Хотя казалось бы IndicatorCounted() должна обеспечивать только пересчёт пропущенных баров, то есть примерно то же самое время, с небольшой экономией за счёт числа вызовов индикатора.

 
Я же говорю, что слишком часто вызывается индикатор с полным пересчётом! И дело не в индикаторе, а в эксперте, который вызывает этот индикатор через раз


Есть еще нюанс.
Мой индикатор строится справа-налево, а не наоборот. Может в этом проблема ???

Взгяните на мой индикатор - он сделан по аналогу Ишимоку, но только мой индикатор строится справа-налево, а вот Ишимоку строится слева-направо.

Как функция IndicatorCounted( ) считает посчитанные бары ?
 

Вот я Вам и советую сделать так же, как и в MACD Sample - заранее заполните переменные рассчитанными значениями индикатора. А уже потом проверяйте условия. Вы удивитесь, насколько быстрее пройдёт тестирование.


Да - тест вошел в "норму" - тоесть быстрее на порядок (вместо часа - около 10 минут). Я бы ни за что сам не догадался о таком нюансе (не имея дебаггера).
Наоборот, вся моя блок-схема была разработана, чтобы как можно меньше обращаться к индикатору, пропускать бары и т.д.
И много еще таких нюансов ?
 
Спасибо за поднятую проблему. Мы сейчас занимаемся этим вопросом - чтобы в тестере не было тотальных пересчётов ни при каких условиях (если конечно пользовательские индикаторы правильно написаны).
 
Если пересчёт при пропуске баров задумывался как средство автоматической обработки докачки истории, то простой пересчёт не всегда делает это корректно (например для индикаторов типа зигзаг, с переписыванием прошлого). По хорошему нужна бы переинициализация. Но гораздо чаще достаточно просто обсчитать только добавленные бары. Мне кажется необязательный параметр в IndicatorCounted, позволяющий при написании индикатора явно указывать тип реакции на докачку истории был бы не лишним. Впрочем, и дополнительное #property не нарушило бы совместимость по исходным текстам.
 
Спасибо за поднятую проблему.


Slawa - чтобы закончить эту тему, нужно еще вот что исправить :
При оптимизации (я вчера пробовал с учетом всех открывшихся нюансов), когда ставишь "Ограничения"- Минимальный баланс (я поставил 5000) - проходит два прохода и дальше проц загружен на 100% а новые проходы не проходит (тоесть стоит на месте).
То же самое происходит, когда я убираю галочку "Пропускать бесполезные результаты" - терминал проходит 2 прохода и дальше не двигается, но загрузка проца 100% - я включал оптимизацию на всю ночь (часов на 9)

Высылаю вам советник и индикатор (в индикаторе ниче не менялось, а в советнике учтен вызов индикатора в функции старт() )
 
Да, я получил письмо. Попробую воспроизвести.
 
Forex Trader:
Спасибо за поднятую проблему. Мы сейчас занимаемся этим вопросом - чтобы в тестере не было тотальных пересчётов ни при каких условиях (если конечно пользовательские индикаторы правильно написаны).
Получилось?
123456
Новый комментарий
Причина обращения: