Тонкие нюансы форвард-оптимизации. Глюк или так задумано? Скорее глюк...
При повторном нажатии Старт тестер либо продолжит оптимизацию (если еще есть что искать, судя по приведенному примеру это не тот случай) или покажет уже готовый кэш из opt-файла (если такой есть подходящий для текущих настроек и хэш-суммы ex5-файла эксперта). При этом, разумеется, эксперт не запускается и никакие фрейме не передаются, т.к. они уже были переданы.
Судя по столбцам в картинках, одна из них с бэктестами (оптимизации), а другая с форвардами. Картинки с 1000 форвардов не вижу.
Для чистоты эксперимента добавьте в исходник эксперта директиву #property tester_no_cache.
PS. Кое-какие нюансы, имеющие отношение к ситуации, описаны в моем блоге (но только на английском, используйте автоперевод по необходимости) - см. раздел Theory.При повторном нажатии Старт тестер либо продолжит оптимизацию (если еще есть что искать, судя по приведенному примеру это не тот случай) или покажет уже готовый кэш из opt-файла (если такой есть подходящий для текущих настроек и хэш-суммы ex5-файла эксперта). При этом, разумеется, эксперт не запускается и никакие фрейме не передаются, т.к. они уже были переданы.
Судя по столбцам в картинках, одна из них с бэктестами (оптимизации), а другая с форвардами. Картинки с 1000 форвардов не вижу.
Для чистоты эксперимента добавьте в исходник эксперта директиву #property tester_no_cache.
Не обратил внимание, точно, после второго нажатия в таблице данные только с бэк-интервала.
Значит, на форварде только 256 лучших вариантов. Значит, глюка нет, значит, так и задумано. (Не, все равно глюк в том, что данные форварда не показываются из кэша.)
С #property tester_no_cache тестирование проходит заново и в таблице только 256 результатов.
Но это не решает вопроса. На форварде нужные точно все те же проходы, как на бэке, без выбора лучших.
Нужно какое-нибудь свойство типа С #property tester_forward_all...
На форварде нужные точно все те же проходы, как на бэке, без выбора лучших.
Так не проще тогда полностью и провести оптимизацию на двух и более участках?
Вроде fxsaber публиковал инструмент для управления настройками оптимизации и запуском/остановкой, я использую именно такой подход, но иную реализацию.
Полагаю, MQ провели статисследование результатов оптимизаций прежде чем выбрать такой лимит в 25% форвардов от исходной оптимизации. Суть в том, что стОящие внимания проходы будут иметь близкие к лучшим значениям по большинству факторов оптимизации (из всего перечня). Иными словами, очень мала вероятность, что проход с лучшим значением по одному фактору окажется вне четверти лучших по какому-либо другому фактору, или что проход будет в топе только по одному фактору.
Но, разумеется, настройку количества форвардов можно было бы сделать (как и многое другого, чего не хватает).
Так не проще тогда полностью и провести оптимизацию на двух и более участках? (1)
Вроде fxsaber публиковал инструмент для управления настройками оптимизации и запуском/остановкой, я использую именно такой подход, но иную реализацию. (2)
(1) Рассматриваю такой вариант. Нужно соответствие проходов на бэкинтервале с форвард интервалами, иначе генетическим алгоритмом не получится пользоваться, а только полным перебором. Тестирование/оптимизация в МТ5 очень быстрая, можно отказаться от генетического алгоритма, может быть, выберу этот вариант.
(2) Видел, знаю. Не хотелось бы использовать то, что в любой момент может перестать работать, поэтоvу никакого WIN API. Смотрел код, там есть очень сомнительные места - вроде как не получается некоторые команды выполнять с первого раза, выполняются паузы, повтор...
Полагаю, MQ провели статисследование результатов оптимизаций прежде чем выбрать такой лимит в 25% форвардов от исходной оптимизации. Суть в том, что стОящие внимания проходы будут иметь близкие к лучшим значениям по большинству факторов оптимизации (из всего перечня). Иными словами, очень мала вероятность, что проход с лучшим значением по одному фактору окажется вне четверти лучших по какому-либо другому фактору, или что проход будет в топе только по одному фактору.
Но, разумеется, настройку количества форвардов можно было бы сделать (как и многое другого, чего не хватает).
Есть предположение, что выбор сигнала (трейдера, фонда на доверительное управление), это не тоже самое, что выбор подходящего набора параметров при оптимизации. Поэтому есть идея поэкспериментировать с выбором на основании различных критериев, а не только одного. Поэтому на форварде нужны все проходы, как на бэке. Есть план создавать свой отчет, в него вносить все показатели... еще всяких своих понапридумывать. Потом сортировать отчет по разным критериям и смотреть на результаты по форварду.
(1) Рассматриваю такой вариант. Нужно соответствие проходов на бэкинтервале с форвард интервалами, иначе генетическим алгоритмом не получится пользоваться, а только полным перебором. Тестирование/оптимизация в МТ5 очень быстрая, можно отказаться от генетического алгоритма, может быть, выберу этот вариант.
Можно закодировать все комбинации настроек, потом через фрейм передавать номер комбинации. При тесте на новом участке использовать уже не настройки широкого диапазона, а номер комбинации, по которому при инициализации будет проходить автонастройка.
(2) Видел, знаю. Не хотелось бы использовать то, что в любой момент может перестать работать, поэтоvу никакого WIN API. Смотрел код, там есть очень сомнительные места - вроде как не получается некоторые команды выполнять с первого раза, выполняются паузы, повтор...
Ну, код не изучал. Использую иной вариант вполне успешно и стабильно. Запустил в работу задания на месяц и никаких хлопот - весьма удобно.
Всё закончится когда либо, но лучше пользоваться сейчас тем, что есть, чем ждать когда этого не будет - мнение.
Можно закодировать все комбинации настроек, потом через фрейм передавать номер комбинации. При тесте на новом участке использовать уже не настройки широкого диапазона, а номер комбинации, по которому при инициализации будет проходить автонастройка.
...
Не, это много лишних движений по подготовке советника. Да и стало понятно, что нужен именно полный перебор.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
MetaTrader5, build 4885.
Форвард оптимизация, полный перебор данных.
У советника оптимизируется один параметр в диапазон от 1 до 1000.
Сначала идет оптимизация на бэк-интервале, в статусной строке отображается что-то типа от 1 до 1000.
Оптимизация на бэк-интервале заканчивается... маленькая пауза... и начинается
тестирование на форвард интервале, и вот тут в статусной строке сообщение - 1 из 256, 2 из 256 и т.д.
Доходим до 256 и оптимизация полностью заканчивается. В терминале в таблице результатов
оптимизации отображается 256 строк.
Вот начало таблицы, отсортированной по номеру прохода по возрастанию:
Тут можно подумать, что так и задумано - оптимизатор выбрал некоторое количество лучших бэк-тестов и
проверил на форфард-интервале только их. Вполне разумно и логично.
Но!
Тут же снова жму кнопку "Start" и через мгновение в таблице результатов отображается вся 1000 строк.
Вот таблица:
Из чего следует вывод - тестирование на форвард интервале не было ограничено 256-ю вариантами,
а было выполнено полностью в соответствии с количеством проходов бэк-оптимизации.
Значит, глюк!
В чем собственно глюк - мнения могут разделиться. Либо при повторном нажатии на "Start"
в таблице результатов оптимизации не должна появляться вся 1000 строк (1). Либо, раз уж имеем 1000
проходом на бэк-интервале, эта же тысяча должна быть выполнена и на форвард-интервале (2).
Лично мне правильным кажется вариант 2 - на форварде должно быть точно такое же
количество проходов, как на бэке (и отображаться тоже должно).
Если кто-то считает правильным вариант 1, аргументы против него. Терминал выбирает бэк-тесты по
максимальному значению. Однако, критерии могут быть разными, может быть наоборот - меньшие
значения критерия означают лучшие результаты тестирования, например, ошибка линейной регрессии.
Более того, хотелось бы формировать свои отчеты об оптимизации с множеством критериев, а для этого
нужно соответствие проходов бэка и форварда.
Допустим ладно - в таблице показаны не все варианты, но раз уж выполнены все проходы, ими как-то можно воспользоваться.
Но не тут-то было. Из тех проходов, которые не отображаются в таблице после первого запуска оптимизации
не происходит отправка фреймов. А после второго запуска, надо полагать, все данные берутся из кэша,
поэтому вообще никакие фреймы не отправляются.