Форвард тестирование стратегий - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Я тоже не гоняю по прибыли на балансе.
Но и не обращать внимания на убыточные результаты бектестов - это заведомая глупость. Лучше уж сразу прогнать подгонку участке, на которому у вас форвард и не заморачиваться, коли для Вас не важно, что там было не беках: профит или убыток.
Угадали, не важно. Важно, чтобы параметры, подобранные по МОЕМУ критерию оптимизации на бэке дали профит на форварде. Мы как бы прогнозируем теперь не ценовой ряд, а поведение баланса (ну или эквити, кому как удобно).
Еще раз повторю. Если Вам важны положительные результаты только на форварде, независимо от беков, то делайте на том самом участке, где у Вас сейчас форвард подгонку по Вашему же критерию оптимизации и Вы получите там эти самые положительные результаты, независимо от результатов на том участке, который у Вас сейчас на беках.
Тем самым сэкономите себе кучу времени и нервов. Нахрена гонять тестер на том участке, который для Вас неважен?
Мне, например, важно, чтобы положительные результаты были и на беках и на форварде. Поскольку на беках оптимизация, а форвардами отсеивается значительная часть подгоночных параметров.
У меня несколько иной взгляд на форвард-тестирование: разновидность подгонки (не обязательно в плохом смысле).
Не вижу причин, почему результаты оптимизационной модели бэктест(Period1) + форвард (Period2) лучше простого бэктест(Period1 + Period2).
Разработка своего критерия оптимизации видится более перспективным направлением получения адекватных настроек стратегии для торговли.
На рынке еще бывают такие ситуации, когда какая-то закономерность резко разрушается/появляется. Ниже пример Equity бэктеста за ~40 дней (~1000 сделок):
Там, где резко вверх пошло - это сотни сделок. И это с большой вероятностью новая закономерность, которая продлится прилично, чтобы успеть заработать. Такие ситуации наблюдал неоднократно. Как с определенного момента появляется закономерность и оптимизировать ее по периодам, которые были ДО, не имеет никакого смысла. Более того - вредно.
Очень важна стат. значимость результата. Фильтрую все резльутаты с количеством сделок < 100.
P.S.
Рынок характеризуется наличием различного рода закономерностей в каждый момент времени. Если обозначить N(t), как функцию количества закономерностей в зависимости от времени и построить ее график. То сразу бросются в глаза провалы - резкое уменьшение количества рыночных закономерностей.
Эти провалы почти всегда соответствуют важным событиям, > 90% из которых являются плановыми - экономические новости по расписанию.
При поиске рыночных закономерностей разумно выбрасывать из анализа подобные периоды провалов N(t), как плановые, так и форс-мажорные. Выбрасывают еще и периоды явных отсутствий искомых закономерностей - специальный автоматизированный фильтр.
Такие действия позволяют значительно увеличить вероятность нахождения закономерности.
Поэтому во время торговли найденной рыночной закономерности прекращается какая-либо торговая деятельность перед выходом запланированной новости и некоторое время после.
Необходимо отслеживать важные новости и соответствующим образом заранее реагировать.
Не вижу причин, почему результаты оптимизационной модели бэктест(Period1) + форвард (Period2) лучше простого бэктест(Period1 + Period2).
Обсуждаемо. Полторы страницы уже написали.
Меня бы устроило расширение ENUM_STATISTICS результатами соответствующего бек-прохода.
И соответственно, чтобы через TesterStatistics можно было к ним добраться (или добавить новую ф-ию TesterBackStatistics, чтобы не расширять ENUM)
+ добавить в ENUM_MQL5_INFO_INTEGER флаг MQL5_OPTIMIZATION_FORWARD для MQL5InfoInteger.
Т. о., в OnInit можно было бы выяснить, что это форвард, и поглядеть, а подходит ли результат форварда для последующего теста? Если нет, сделать ExpertRemove().
+ в OnTester можно дополнительно анализировать результат соответсвующего бек-прохода и сформировать новый критерий (что-то вроде, если профит-фактор бек-прохода больше в более чем 2 раза форвард-прохода, то забраковать такой проход; ну или сложить\умножить\поделить балансы\стат. данные - вариантов масса).
Если бы это было, то можно ставить хоть 100% результатов на бектест - с помощью одного "if" я смогу пропустить ненужный мне вариант.
Ничего городить не надо, если понимать суть. Форвардное тестирование - один из (бесконечного числа) вариантов критерия оптимизации.
Очевидно, что оба варианта дадут один и тот же результат. Если бы первого варианта не было (нет форварда), то вы бы ничего не потеряли в гибкости оптимизации. Т.к. используя механизм создания собственного критерия оптимизации, смогли бы полностью воспроизвели форвард-тестирование. При этом вы можете его сделать сколь угодно гибким, насколько только позволяет фантазия.
Данная ветка и само форвард-тестирование, как отдельная фишка, полностью теряют смысл. Создавайте свои критерии и ни от кого не зависьте.
А ведь вы можете на базе MT5-оптимизатора создать ( раз уж так нравится MQL5) свой тестер (даже с кастомной историей), который будет удовлетворять всем вашим потребностям. Ведь что такое тестер: это преобразование входных ценовых ВР в один ценовой ряд под названием Equity. При этом функционалом преобразования является ваша стратегия. Т.е. Equity_tester - это один из вариантов критерия оптимизации, написание которого много проще, чем написание профитной стратегии. И тогда вы станете еще более свободны от возможностей и хотелок разработчиков.
Данная ветка и само форвард-тестирование, как отдельная фишка, полностью теряют смысл. Создавайте свои критерии и ни от кого не зависьте.
Согласен с вами. Но я в начале этой ветки попытался обратить внимание на другой вопрос - на проблему переоптимизации параметров, которую можно решить только путём анализа форвард тестирования стратегии на всех бэк-проходах (см. рис. на первой стр. топика). Поэтому, только 100%.
И ещё. Пусть у нас имеется некоторая закономерность во временном ряде, которую мы наблюдаем в течении N-отсчётов (выявили её на бэк-участке) и не знаем когда она началась и когда закончится, но знаем, что полная длина закономерности есть случайная величина с каким-то законом распределения. Вопрос: какое количество отсчётов, вероятнее всего, она ещё просуществует? Это к вопросу об оптимальной длине форвард-участка (ФУ).
Понятно, что кусок ВР занятый справа ФУ укорачивает время существования выявленной на БУ закономерности ровно на длину ФУ, что не есть гуд. С другой стороны, с точки зрения оптимизации параметров, ВР симметричен как в прошлое, так и в будущее и нет никакой разницы с какой стороны БУ (влево или вправо относительно начала и конца ВР соответственно) начинать форвард-тестирование. Поэтому, было бы замечательно иметь возможность выбирать область сразу слева от БУ или сразу справа от него из консоли тестера. Это позволит начинать торговлю сразу за участком тестирования не рискуя начать работу на уже прокисших данных.
Если же использовать ФУ только для валидации параметров стратегии, то я согласен с hrenfx в том, что это неимеет никакого смысла в том плане, что бэктест(Period1) + форвард (Period2) тождественно бэктест(Period1 + Period2).
Важно
Форвард тестирование нужно только для выявления области переоптимизации параметров и бессмысленно для валидации стратегии. В тестере реализован именно последний вариант.
Еще раз повторю. Если Вам важны положительные результаты только на форварде, независимо от беков, то делайте на том самом участке, где у Вас сейчас форвард подгонку по Вашему же критерию оптимизации и Вы получите там эти самые положительные результаты, независимо от результатов на том участке, который у Вас сейчас на беках.
Тем самым сэкономите себе кучу времени и нервов. Нахрена гонять тестер на том участке, который для Вас неважен?
Мне, например, важно, чтобы положительные результаты были и на беках и на форварде. Поскольку на беках оптимизация, а форвардами отсеивается значительная часть подгоночных параметров.
У нас разные задачи.
Только 100% (или возможность выбора).