Идеальная механическая торговая система. - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мне пока всё представляется гораздо проще. Начать нужно с какой-то простейшей, наивной системы, с минимумом параметров настройки. И дописать к ней блок адаптивного изменения параметров в реальном времени...
Вот-вот, осталась самая малость:) надо определиться какие данные использовать для расчета адаптивных параметров. Даже и не знаю что предложить :(
Может у кого-нибудь есть идеи по этому поводу?
Могу для начала предложить такую модель ТС:
Берем простинького эксперта и пишем к нему блок "тестера" (в задачу которого будет входить - 1 раз в сутки например в 01:00 по GMT подгонка ТС под месячную историю).
xeon, тестер можно сделать хоть постоянно работающим. Писать разумеется его придется уже на высокооптимизированном С, а не на mql4. Увы, во всём этом есть один очень серьезный подводный камень. А именно период оценки и оптимизации системы. Т.е. за какое время оценивать её деятельность ? Положим у нас за право реальной торговли конкурируют две стратегии. Успешная текущая, и худшая резервная. В течении какого-нибудь часа например, текущая стратегия слила, а резервная наоборот добилась успеха. Вопрос менять стратегии или не менять ? Ведь это может быть как началом новой тенденции (не путать с трендом/флетом !), так и случайностью. Т.е. получается что сам такой тестер будет иметь по крайней мере один (и важный !!!) настраиваемый параметр - период оценки и оптимизации. Не пойми, что я говорю о невозможности такого подхода. Я просто говорю что во всём этом есть свои трудности и туманные места.
Давайте всё-таки попробуем с простого.
Задача: можно ли написать функцию, которая раз в сутки прогоняет месячную историю и за параметр стоплосса ставит оптимальное число?
И САМОЕ ГЛАВНОЕ: можно ли с этой функцией проверять на тестере? Будет ли вообще тестер работать? Получается что каждые сутки в режиме теста он должен менять параметр стопа на новый день? Возможно ли это? Если решить эту задачу, остальное как уже сказали - глазурь.
xeon, тестер можно сделать хоть постоянно работающим. Писать разумеется его придется уже на высокооптимизированном С, а не на mql4. Увы, во всём этом есть один очень серьезный подводный камень. А именно период оценки и оптимизации системы. Т.е. за какое время оценивать её деятельность ? Положим у нас за право реальной торговли конкурируют две стратегии. Успешная текущая, и худшая резервная. В течении какого-нибудь часа например, текущая стратегия слила, а резервная наоборот добилась успеха. Вопрос менять стратегии или не менять ? Ведь это может быть как началом новой тенденции (не путать с трендом/флетом !), так и случайностью. Т.е. получается что сам такой тестер будет иметь по крайней мере один (и важный !!!) настраиваемый параметр - период оценки и оптимизации. Не пойми, что я говорю о невозможности такого подхода. Я просто говорю что во всём этом есть свои трудности и туманные места.
Давайте всё-таки попробуем с простого.
Задача: можно ли написать функцию, которая раз в сутки прогоняет месячную историю и за параметр стоплосса ставит оптимальное число?
И САМОЕ ГЛАВНОЕ: можно ли с этой функцией проверять на тестере? Будет ли вообще тестер работать? Получается что каждые сутки в режиме теста он должен менять параметр стопа на новый день? Возможно ли это? Если решить эту задачу, остальное как уже сказали - глазурь.
Насколько я знаю подобную функцию тестера написать на mql можно, но задача эта для меня не простая так как я "программист любитель" и мне требуется время что-бы это сделать.
Самонастраивающиеся индикаторы - это тупиковое направление. Попробую обосновать мое мнение.
Я разработал несколько таких индикаторов, но они оказались чувствительны к волатильности котировок, поступающих из разных ДЦ. Т. е. эти индикаторы отлично работают на данных одного ДЦ и совсем не работают на данных другого. Хуже всего работают на данных НС. Усредненное движение котировок в ДЦ одинаковое, а волатильность различается, что сбивает индикатор с толку. Например, даже на стандартных индикаторах на одном и том же интервале котировок в одном ДЦ дивергенция есть, а в другом - нет.
Мои исследования показали, что именно волатильность является ведущим фактором, который должен учитываться в самонастраивающемся индикаторе. Однако, в итоге индикатор становится зависимым от способа фильтрации котировок в разных ДЦ и от изменения этого способа (о чем ДЦ не уведомляет).
Здесь я также столкнулся с тем, что "загрубить" (о чем все время говорит Ренат) самонастройку нельзя, поскольку она является постоянной (линейной), а не дискретной.
Полагаю, что уйти от проблемы волатильности можно только отказавших от учета абсолютных значений индикаторов и котировок. Т.е. для принятия решения в МТС следует использовать соотношение значений в том или ином виде, а это уже по сути распознавание образов.
оно!
Самонастраивающиеся индикаторы - это тупиковое направление. Попробую обосновать мое мнение.
Я разработал несколько таких индикаторов, но они оказались чувствительны к волатильности котировок, поступающих из разных ДЦ. Т. е. эти индикаторы отлично работают на данных одного ДЦ и совсем не работают на данных другого. Хуже всего работают на данных НС. Усредненное движение котировок в ДЦ одинаковое, а волатильность различается, что сбивает индикатор с толку. Например, даже на стандартных индикаторах на одном и том же интервале котировок в одном ДЦ дивергенция есть, а в другом - нет.
Мои исследования показали, что именно волатильность является ведущим фактором, который должен учитываться в самонастраивающемся индикаторе. Однако, в итоге индикатор становится зависимым от способа фильтрации котировок в разных ДЦ и от изменения этого способа (о чем ДЦ не уведомляет).
Здесь я также столкнулся с тем, что "загрубить" (о чем все время говорит Ренат) самонастройку нельзя, поскольку она является постоянной (линейной), а не дискретной.
Полагаю, что уйти от проблемы волатильности можно только отказавших от учета абсолютных значений индикаторов и котировок. Т.е. для принятия решения в МТС следует использовать соотношение значений в том или ином виде, а это уже по сути распознавание образов.
Для любой системы важны не значения цены, а скорость ее изменения (иногда просто знак).
Иногда используют ускорение цены (оценка силы действующей на цену, как опережающий индикатор).
ВСЕ индикаторы используемые с МТС фактически предназначены для оценки скорости.
Разные индикаторы - это просто разные ВАРИАНТЫ оценки скорости.
1. ВСЕ осциляторы оценивают скорость, иногда ускорение (как MACD).
2. ВСЕ скользящие средние НИКОГДА не используются сами по себе,
только в сравнении с другими скользящими (цена - это мувинг с длиной = 1).
Это сравнение скользящих (фактически сравнение их разности с нулем) - это осцилятор.
3. Рассматривать нужно не цену, а логарифм цены.
В логарифмах все становится проще и правильнее.
При малых изменениях цены разницы между работой с ценой и логарифмом не будет,
при больших изменениях цены разница будет существенно.
Можно я сделаю маленькую подсказку? :)
Для любой системы важны не значения цены, а скорость ее изменения (иногда просто знак).
Иногда используют ускорение цены (оценка силы действующей на цену, как опережающий индикатор).
ВСЕ индикаторы используемые с МТС фактически предназначены для оценки скорости.
Разные индикаторы - это просто разные ВАРИАНТЫ оценки скорости.
1. ВСЕ осциляторы оценивают скорость, иногда ускорение (как MACD).
2. ВСЕ скользящие средние НИКОГДА не используются сами по себе,
только в сравнении с другими скользящими (цена - это мувинг с длиной = 1).
Это сравнение скользящих (фактически сравнение их разности с нулем) - это осцилятор.
3. Рассматривать нужно не цену, а логарифм цены.
В логарифмах все становится проще и правильнее.
При малых изменениях цены разницы между работой с ценой и логарифмом не будет,
при больших изменениях цены разница будет существенно.
а может еще и примите участие в написании кода? :-), с вашим опытом программирования дело пошло-бы гораздо быстрее!