Альтернативная оптимизация ТС - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Проще ничего не делать.
В идее топикстартера есть резон. Он в том, что для того, чтобы узнать вкус борща, не обязательно съедать всю кастрюлю целиком.
Но я ее реализую в другом плане. Просто для меня конечная задача тестирования -это выбор более удачного кода, а не параметров.
Т.е. для того, чтобы узнать какая кастрюля борща лучше можно попробовать из каждой и сравнить, не съедая ни ту ни другую.
Поэтому я не совершаю все мыслимые сделки с последующим анализом
Я совершаю автотестером все возможные из существующих параметров сделки на начальном этапе и сравниваю результаты волк-форварда для разных версий советника. Если проверяемая версия явно хуже эталонной для данного отрезка истории, то я экономлю время, отбрасывая саму версию советника на ранних этапах а не прогоняю все тестирование до конца. Если результат попадает в допуск, то перехожу к следующему этапу и тд. Иногда, конечно, бывает, что проверяемая версия выигрывает не сразу, а по итогам всего отрезка истории, но крайне редко. Обычно идея, неудачная на короткой дистанции неудачна и на длинной.
Другое дело, когда надо выбрать оптимальную длительность обучения и шаг самого волк-форварда. Когда гоняешь волк-форвард одного и того же советника, но на разных диапазонах, действительно, получается что приходится многократно совершать одни и те же сделки с одними и теми же параметрами просто во имя того, чтобы поучить результаты с разных но все же пересекающихся отрезков истории.То же самое относится и к критериям оптимизации.
Тут, конечно, рациональнее потерпеть и сначала получить за один проход все результаты на длительной истории, а потом их анализировать хоть до посинения. Все равно анализ уже готовых результатов заведомо быстрее повторных проходов.
Т.е., на мой взгляд, право на существование имеют оба подхода, но только в зависимости от конечной цели тестирования.
Можно проводя пакетное тестирование, разбив прогоны аналогично вложенным for, при первом проходе записывать в массив время, в которое выполнялось самое тяжелое для расчетов условие. А в следующих прогонах заменить эти вычисления на функцию, типа той что в кодобазе: https://www.mql5.com/ru/code/16416 Только дописать чтоб дату отслеживала. Время сна установить=минимальному времени между соседними выполненными условиями. И индикаторы, которые больше не будут использоваться, выгрузить.
В этом случае отложенные ордера, ТП и СЛ должны срабатывать, но вычислений лишних не будет.
А лучше даже новую функцию написать - которая будет "усыплять" математику ровно на время бесполезных колебаний цены.