У Вас тема неправильная. Вы концентрируетесь на оптимизации, а дело, очевидно, в советнике (передача параметров и пр.). Забудьте на время об оптимизации, натыкайте в советник comment'ов и принтов, погоняйте с разными параметрами в визуале, контролируя промежуточные данные, найдите все ошибки, а потом вернетесь к оптимизации.
Одинаковые результаты свидетельствуют о том, что оптимизируемые параметры не влияют на формирование торгового сигнала, а это проблема советника, а не тестера.
Если я задаю параметры так: (iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); - то получаются все нули, как я привела пример выше.
Если я задаю iCustom(NULL, 0, "ART", 0, 1), Digits); - то появляются расчетные значения,
но они все одинаковые, хотя в тесторе при прогонах с разными параметрами результаты сделок сильно отличаются.
Angela, чтобы оптимизация работала, нужно как-то использовать изменяемые оптимизатором значения в алгоритме, в частности передавать в индикатор. Индикатору обязательно нужно передавать параметры, если Вы хотите оптимизации. Когда Вы вызываете индикатор без параметров (т.е. второй вариант, iCustom(NULL, 0, "ART", 0, 1)), то фактически опускаете параметры и индикатор работает с параметрами по-умолчанию, которые прописаны внутри ART (разумеется при этом они не оптимизируются). Полный вызов с параметрами - первый вариант - это то, что Вам нужно для оптимизации. Скорее всего, проблема в том, что Вы неправильно передаете параметры. Например, если их число в индикаторе меньше, и Вы передаете личшнее значение или наоборот, если не додаете всех параметров. Если индикатор - секрет, то хотя бы приведите перечень его параметров.
Поздравляю. Помню, тоже мучился с передачей параметров, пока не приучил себя к скрупулезности. Теперь кусок кода индикатора со всеми extern'ами копипастю в советник и пишу iCustom, глядя на образец. Туповато, но с тех пор ошибок нет.
И еще. Подсмотрел у komposter'а наглядный стиль написания iCustom. Все как на ладони.
/*
Входные параметры индикатора
extern int FastEMA=12;
extern int SlowEMA=26;
extern int SignalSMA=9;
*/double signal=iCustom(Symbol(),Period(),"MACD",
FastEMA,//параметр 1
SlowEMA,//параметр 2
SignalSMA,//параметр 30,//номер буфера индикатора
SignalBar);//бар, с которого получаем данные (внешняя переменная)
Отлаживаю второй вариант ТС, по сравнению с первой, количество сделок прибавилось, существенно уменьшилось количество оптимизируемых параметров, хотя и просадка возросла в два раза.
Но меня гложат смутные сомнения, система ведет себя не очень устойчиво от месяца к месяцу, пока не оптимизировала, оптимизацию запустила, но результат с использованием ГА будет только через двое суток.Прошедшие более 800 прогонов оптимизма не внушают, результаты оптимизации на истории за июнь хуже, чем при тестировании с начальными параметрами на этом же периоде. Привожу три стейта, за июнь, июль и август, пока отлаживаю только Buy, можно ли вытянуть такую систему за счет оптимизации на стабильные результаты, или следуют сразу начать разрабатывать новую?
Если в эксперте участвует только mql-код, то что-то там видимо не так закодировано, потому что при модели по ценам открытия 800 прогонов не должны так тормозить. Или я чего-то недопонимаю. Обычно настолько задумчивыми бывают эксперты с внешней обвязкой типа нейросетевых библиотек и пр. Можно конечно еще предположить, что в mql-е сочинено много вложенных циклов (или вызовов неких "прожорливых" индикаторов) - тогда и его можно капитально затормозить. В связи с чем могу лишь повторить мысль о предполагаемой необходимости рефакторинга ;-) - перепроверки и переиначивания фрагментов кода или всего кода.
marketeer писал(а)>> Если в эксперте участвует только mql-код, то что-то там видимо не так закодировано, потому что при модели по ценам открытия 800 прогонов не должны так тормозить. Или я чего-то недопонимаю. Обычно настолько задумчивыми бывают эксперты с внешней обвязкой типа нейросетевых библиотек и пр. Можно конечно еще предположить, что в mql-е сочинено много вложенных циклов (или вызовов неких "прожорливых" индикаторов) - тогда и его можно капитально затормозить. В связи с чем могу лишь повторить мысль о предполагаемой необходимости рефакторинга ;-) - перепроверки и переиначивания фрагментов кода или всего кода.
800 из более 8000 прогонов прошли к моменту написания поста, при 5 часовой оптимизации, и оставалось по времени еще 2 суток. Но я не стала дожидаться окончания, уменьшила диапазон перебора некоторых параметров, перезапустила и за 8 часов прошла вся оптимизация.
Количество прибыльных сделок превышает количество убыточных, средняя прибыльная сделка больше убыточной - очень хороший признак. По моему, отказываться от этой системы не стоит, надо как следует изучить ее поведение на большем периоде. Также можно поставить ее на другой кросс.
То есть меняется только эта строка с iCustom? Тогда надо этот индикатор подробно рассмотреть.
У Вас тема неправильная. Вы концентрируетесь на оптимизации, а дело, очевидно, в советнике (передача параметров и пр.). Забудьте на время об оптимизации, натыкайте в советник comment'ов и принтов, погоняйте с разными параметрами в визуале, контролируя промежуточные данные, найдите все ошибки, а потом вернетесь к оптимизации.
Одинаковые результаты свидетельствуют о том, что оптимизируемые параметры не влияют на формирование торгового сигнала, а это проблема советника, а не тестера.
Если я задаю параметры так: (iCustom(NULL, 0, "ART", MA_Period, KFK, 0, 1), Digits); - то получаются все нули, как я привела пример выше.
Если я задаю iCustom(NULL, 0, "ART", 0, 1), Digits); - то появляются расчетные значения,
но они все одинаковые, хотя в тесторе при прогонах с разными параметрами результаты сделок сильно отличаются.
Angela, чтобы оптимизация работала, нужно как-то использовать изменяемые оптимизатором значения в алгоритме, в частности передавать в индикатор. Индикатору обязательно нужно передавать параметры, если Вы хотите оптимизации. Когда Вы вызываете индикатор без параметров (т.е. второй вариант, iCustom(NULL, 0, "ART", 0, 1)), то фактически опускаете параметры и индикатор работает с параметрами по-умолчанию, которые прописаны внутри ART (разумеется при этом они не оптимизируются). Полный вызов с параметрами - первый вариант - это то, что Вам нужно для оптимизации. Скорее всего, проблема в том, что Вы неправильно передаете параметры. Например, если их число в индикаторе меньше, и Вы передаете личшнее значение или наоборот, если не додаете всех параметров. Если индикатор - секрет, то хотя бы приведите перечень его параметров.
Спасибо всем, разобралась, причина была бональной.порядок рбъявления передаваемых из индикатора в советник параметров не совпадал:
в советнике было
extern int MA_Period=151; // 101 10 201
extern double KFK=0.9; // 0.7 0.005 1.
в индикаторе наоборот
extern double KFK=0.9; // 0.7 0.005 1.
extern int MA_Period=151; // 101 10 201
из-за этого в режиме визуализации все работало, в режиме оптимизации - нет.
Поздравляю. Помню, тоже мучился с передачей параметров, пока не приучил себя к скрупулезности. Теперь кусок кода индикатора со всеми extern'ами копипастю в советник и пишу iCustom, глядя на образец. Туповато, но с тех пор ошибок нет.
И еще. Подсмотрел у komposter'а наглядный стиль написания iCustom. Все как на ладони.
Отлаживаю второй вариант ТС, по сравнению с первой, количество сделок прибавилось, существенно уменьшилось количество оптимизируемых параметров, хотя и просадка возросла в два раза.
Но меня гложат смутные сомнения, система ведет себя не очень устойчиво от месяца к месяцу, пока не оптимизировала, оптимизацию запустила, но результат с использованием ГА будет только через двое суток.Прошедшие более 800 прогонов оптимизма не внушают, результаты оптимизации на истории за июнь хуже, чем при тестировании с начальными параметрами на этом же периоде. Привожу три стейта, за июнь, июль и август, пока отлаживаю только Buy, можно ли вытянуть такую систему за счет оптимизации на стабильные результаты, или следуют сразу начать разрабатывать новую?
Если в эксперте участвует только mql-код, то что-то там видимо не так закодировано, потому что при модели по ценам открытия 800 прогонов не должны так тормозить. Или я чего-то недопонимаю. Обычно настолько задумчивыми бывают эксперты с внешней обвязкой типа нейросетевых библиотек и пр. Можно конечно еще предположить, что в mql-е сочинено много вложенных циклов (или вызовов неких "прожорливых" индикаторов) - тогда и его можно капитально затормозить. В связи с чем могу лишь повторить мысль о предполагаемой необходимости рефакторинга ;-) - перепроверки и переиначивания фрагментов кода или всего кода.
800 из более 8000 прогонов прошли к моменту написания поста, при 5 часовой оптимизации, и оставалось по времени еще 2 суток. Но я не стала дожидаться окончания, уменьшила диапазон перебора некоторых параметров, перезапустила и за 8 часов прошла вся оптимизация.
Самый лучший результат:
Количество прибыльных сделок превышает количество убыточных, средняя прибыльная сделка больше убыточной - очень хороший признак. По моему, отказываться от этой системы не стоит, надо как следует изучить ее поведение на большем периоде. Также можно поставить ее на другой кросс.