Как написать робастного эксперта - страница 15
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Перечитал ветку - большинство постов всё-таки о робастности торговых систем (о чём неплохо было бы завести отдельную тему). Однако, например я считаю, что вопрос устойчивости непосредственно эксперта не менее важен. Посему хотелось бы в этом топике обсуждать то, о чём выше говорили Renat и Rosh:
И действовать по алгоритму, предложенному -Alexey-:
1) кто-то пишет проблемный момент и желающие раскрывают свое видение этой проблемы, на что она может влиять;
2) далее желающие предлагают идеи по его обработке, обсуждают их;
3) далее программисты пишут код в портируемом в эксперт виде и вместе доводят его(конечно, совместимый с МКЛ4 - без классов и т.д., кому надо, потом переделают);
4) подводится результат в виде короткого описания проблемы, описания идеи решения, описания в виде кода;
Что касается робастности эксперта, я бы выделил два типа ошибок: 1) которые можно выловить в процессе отладки и тестирования (например, ошибочные объём, сл, тп и т.д.), 2) связанные с различными сбоями - то бишь корректной работой эксперта после обрывов связи и/или отсутствием таковой некоторое время. Как по мне, способы выявить вторые - это думать на тему "что если ...?", либо же наступать на грабли в рил-тайме (что крайне неприятно).
Ну и от теории к практике.
Момент, на который обратил внимание - обработчики события нового бара. Возможно, ошибаюсь, но то, что видел здесь, можно описать примерно так:
получили время текущего бара -> сравнили с предыдущим -> если отличается, обновили значение предыдущего -> сообщили, что бар новый (return(true)) -> дальше чего душа пожелает (проверяем сигналы, открываем/закрываем позиции и т.д.)
А что, если после проверки нового бара, но до выполнения "чего-душа пожелает" случился тот самый обрыв связи? Результат - больше на этом баре проверок не будет, тк он уже "старый", и задуманное будет не выполненым (скажем, останется открытой позиция). Может слишком заморачиваюсь, и проблема чисто теоретическая, но на всякий случай решаю её так:
получили и сравнили время текущего бара -> сделали всё, что хотели -> и только в случае успешного выполнения всех действий обновили время.
В результате и гарантировано выполнение действий, и не придётся делать проверки на каждом тике. Отсюда первое: хорошо бы услышать, кто что думает по этому поводу.
И второе (как раз о том, что было вверху этой страницы):
Допустим эксперт использует индикаторы.
Прекрасная ветка форума! Очень много подчеркнул интересного и забавного...
Особенно понравились коменты: comment_85767 comment_86101 comment_86244 comment_87490 comment_87729 comment_87750 comment_87886 comment_88147 comment_88151 comment_88514 comment_90820 comment_90995 comment_91004
comment_327195 comment_327435 comment_328238 comment_328915 comment_329844 comment_332955
Хотелось бы кроме мыслей по поводу торговых стратегий, фильтрации, манименджмента, ещё конкретизировать некоторые технические моменты, касательно всяких непредвиденных ситуаций. Некоторые названы были уже, такие как: обрыв связи, проблемы с немгновенным выполнением функций, генерацией индикаторов...
Хочется собрать список из рейтинговых 10-20 таких технических "подводных камней", ну и совсем будет круто, если со ссылками на примеры реализации их решения. Я так понял изначально тема именно про это должна была быть, а плавно перетекла на "высокие материи" такие как ТСы и их оптимизация. Хотя получилось очень интересно))
Хотелось бы кроме мыслей по поводу торговых стратегий, фильтрации, манименджмента, ещё конкретизировать некоторые технические моменты, касательно всяких непредвиденных ситуаций. Некоторые названы были уже, такие как: обрыв связи, проблемы с немгновенным выполнением функций, генерацией индикаторов...
Хочется собрать список из рейтинговых 10-20 таких технических "подводных камней", ну и совсем будет круто, если со ссылками на примеры реализации их решения. Я так понял изначально тема именно про это должна была быть, а плавно перетекла на "высокие материи" такие как ТСы и их оптимизация. Хотя получилось очень интересно))
Как по мне, пока не начнешь торговать на реале, ни какой рейтинг не поможет.
Готовься - не готовься, а сюрпризы будут )
Это первый водораздел. Знаю два подхода к автоматической торговле (не торговой системе) и они упоминаются как в книгах, так и на форумах:
- первый - устойчивая система должна прибыльно торговать годами;
- второй - не надо пытаться создать систему, которая должна работать годами, нужно подбирать для каждого текущего периода (неделя, месяц, год и так далее) соответствующую ей торговую стратегию.
Как говорится, почувствуйте разницу.Первый подход был бы очень хорош, если бы он был реален.
Системы, работающие прибыльно годами на реале встречаются, но очень редко, что говорит скорее о том, что это случайность - например, у одной из 100 систем, имевших изначально почти одинаковые показатели надежности исходя из качества тестинга и опитимизации, в итоге работоспособность сохранится в течении долгого времени. На практике большинство систем перестают работать достаточно быстро (от пары месяцев до пары лет). Поэтому для успешного автотрейдинга нужно постоянно находится в поиске новых алгоритмов и тщательно следить за сохранением работоспособности своих систем.
Главная проблема в автотрейдинге это проблема подгонки.
Подгонка - это нахождение путем перебора входных параметров такого их сочетания, при котором на данной конкретной тестовой истории робот показывает положительный результат, который обусловлен не наличием рыночной закономерности, а тонкой подстройкой параметров робота к конкретным прошлым изменениям цены, в результате чего создается иллюзия работоспособности, которая оборачивается крахом при постановке такого робота на реальные счета.
Два основных правила для избегания подгонки при разработке и оптимизации системы это статистическая достоверность и форвард-тесты. Достоверность достигается наращиванием кол-ва сделок. Точного правила относительно достоверного количества не существует, но по логике оно должно зависеть от количества степеней свободы - используемых для оценки ситуации экспертом рыночных данных и количества оптимизируемых параметров. Если сделок меньше 500 (а лучше 1000), то к результатам тестов нужно относиться особенно осторожно. Меньше 300 сделок вообще нет смысла рассматривать. Период истории, за который получены эти сделки, не имеет особого значения. Хотя работа на всей доступной истории является существенным преимуществом, нет абсолютной необходимости проверять систему на всей доступной истории, нужно лишь, чтобы закономерность с достоверностью проявляла себя в настоящий момент.
Форвард тесты это второй основной метод для избегания подгонки. Но проблема в том, что многие не понимают сущности этого метода и используют его не правильно. Классически форвард определяется так: при оптимизации робота используемый период истории разделяется на период бэктеста и период форварда, соотношение которых где-то от 5 к 1 до 4 к 1. Оптимизация проводится на бэктест-периоде и после получения результата (улучшенных параметров), проводится тест на форвард периоде для проверки адекватности полученных результатов. Если на форвард периоде улучшенные параметры не дали улучшения результата, значит, результат оптимизации на бэктесте является подгонкой и его нельзя использовать. Но проблема в том, что если мы возьмем два варианта оптимизации: первый - оптимизация до лучшего варианта на всем периоде без разделения на бэк и форвард, и второй - оптимизация на бэк периоде и проверка на форварде, причем результаты, не прошедшие проверку на форварде, будут отбрасываться и тестинг на бэк-периоде будет продолжаться дальше до тех пор, пока не пройдет проверку на форварде, то эти два варианта оптимизации рано или поздно придут к одинаковому результату, совершенно не защищенному от подгонки. Так произойдет потому, что применение форвард-периода не исключает возможность подгонки, а лишь уменьшает вероятность подгонки, т.к. гораздо менее вероятно, что подогнанный результат покажет улучшение также и на независимом периоде. Но последовательно применяя форвард к ряду разных результатов, мы рано или поздно находим тот, при котором на форвард периоде действительно результаты улучшились, однако, поскольку мы занимались перебором, вероятность того, что этот результат не подогнанный, не выше, чем если бы мы просто проводили оптимизацию на всем периоде.
AntFX:
Но проблема в том, что если мы возьмем два варианта оптимизации: первый - оптимизация до лучшего варианта на всем периоде без разделения на бэк и форвард, и второй - оптимизация на бэк периоде и проверка на форварде, причем результаты, не прошедшие проверку на форварде, будут отбрасываться и тестинг на бэк-периоде будет продолжаться дальше до тех пор, пока не пройдет проверку на форварде, то эти два варианта оптимизации рано или поздно придут к одинаковому результату, совершенно не защищенному от подгонки.
Могу вас обрадовать, вы видимо тоже не понимаете сущности этого метода )
Это все, что вы можете сказать по теме? ) Я прекрасно понимаю сущность этого метода, поэтому и пишу.
Форвард тест это не метод избегания подгонки. Это метод оценки работы системы после оптимизации вне периода оптимизации. И не более того.
Рассуждать о том или ином методе оптимизации параметров и тестирования системы без анализа результатов какой либо конкретной системы, рассуждать ни о чём. Это всё очень абстрактно, так как нет результатов, которые можно было бы проанализировать и при этом попытаться выяснить: "Почему система на одних незнакомых данных, после оптимизации на каком-то конкретном участке, показывает положительный результат, а на других незнакомых данных результат вплоть до противоположного?".
Форвард тест это не метод избегания подгонки. Это метод оценки работы системы после оптимизации вне периода оптимизации. И не более того.
Значит в вашем понимании это так. А в моем понимании это именно метод избегания подгонки. Если вы не используете этот метод для анализа адекватности полученных при оптимизации результатов, вы многое теряете.Не только в моём. Изначально идея этого метода (форвард-тест) заключается именно в том, чтобы произвести оценку результатов на незнакомых для системы данных. А вот, что Вы делаете, чтобы избежать подгонки на периоде оптимизации? ))
Количество сделок важно, но опять же, для какого-то конкретного участка с определённым характером поведения цены, на котором была произведена оптимизация параметров. Но эта мысль тоже абстрактна и ни о чём конкретно не говорит, так как в принципе выражена вне контекста, какой-то конкретной системы и не даёт конкретного инструмента для оценки характера поведения цены, который является частью системы. ))
Этот метод нужен и он используется всеми в той или иной степени. Нужно ведь как-то, хотя бы приблизительно, оценить устойчивость работы системы. Просто многие спешат в бой и ломают много копий, проводя по сути форвард-тест на реальных счетах. Большая работа. ))