Идеальная механическая торговая система. - страница 4

 
sashken писал (а):
eugenk1 wrote:
Мне пока всё представляется гораздо проще. Начать нужно с какой-то простейшей, наивной системы, с минимумом параметров настройки. И дописать к ней блок адаптивного изменения параметров в реальном времени...

Вот-вот, осталась самая малость:) надо определиться какие данные использовать для расчета адаптивных параметров. Даже и не знаю что предложить :(
Может у кого-нибудь есть идеи по этому поводу?

Могу для начала предложить такую модель ТС:
    Берем простинького эксперта и пишем к нему блок "тестера" (в задачу которого будет входить - 1 раз в сутки например в 01:00 по GMT подгонка ТС под месячную историю).
 
xeon, тестер можно сделать хоть постоянно работающим. Писать разумеется его придется уже на высокооптимизированном С, а не на mql4. Увы, во всём этом есть один очень серьезный подводный камень. А именно период оценки и оптимизации системы. Т.е. за какое время оценивать её деятельность ? Положим у нас за право реальной торговли конкурируют две стратегии. Успешная текущая, и худшая резервная. В течении какого-нибудь часа например, текущая стратегия слила, а резервная наоборот добилась успеха. Вопрос менять стратегии или не менять ? Ведь это может быть как началом новой тенденции (не путать с трендом/флетом !), так и случайностью. Т.е. получается что сам такой тестер будет иметь по крайней мере один (и важный !!!) настраиваемый параметр - период оценки и оптимизации. Не пойми, что я говорю о невозможности такого подхода. Я просто говорю что во всём этом есть свои трудности и туманные места.
 
eugenk1 писал (а):
xeon, тестер можно сделать хоть постоянно работающим. Писать разумеется его придется уже на высокооптимизированном С, а не на mql4. Увы, во всём этом есть один очень серьезный подводный камень. А именно период оценки и оптимизации системы. Т.е. за какое время оценивать её деятельность ? Положим у нас за право реальной торговли конкурируют две стратегии. Успешная текущая, и худшая резервная. В течении какого-нибудь часа например, текущая стратегия слила, а резервная наоборот добилась успеха. Вопрос менять стратегии или не менять ? Ведь это может быть как началом новой тенденции (не путать с трендом/флетом !), так и случайностью. Т.е. получается что сам такой тестер будет иметь по крайней мере один (и важный !!!) настраиваемый параметр - период оценки и оптимизации. Не пойми, что я говорю о невозможности такого подхода. Я просто говорю что во всём этом есть свои трудности и туманные места.

Давайте всё-таки попробуем с простого.
Задача: можно ли написать функцию, которая раз в сутки прогоняет месячную историю и за параметр стоплосса ставит оптимальное число?
И САМОЕ ГЛАВНОЕ: можно ли с этой функцией проверять на тестере? Будет ли вообще тестер работать? Получается что каждые сутки в режиме теста он должен менять параметр стопа на новый день? Возможно ли это? Если решить эту задачу, остальное как уже сказали - глазурь.
 
а если трейлинг стоп зависит от мацд то можно ли это назвать адаптирущейся смой?
 
quality писал (а):
eugenk1 писал (а):
xeon, тестер можно сделать хоть постоянно работающим. Писать разумеется его придется уже на высокооптимизированном С, а не на mql4. Увы, во всём этом есть один очень серьезный подводный камень. А именно период оценки и оптимизации системы. Т.е. за какое время оценивать её деятельность ? Положим у нас за право реальной торговли конкурируют две стратегии. Успешная текущая, и худшая резервная. В течении какого-нибудь часа например, текущая стратегия слила, а резервная наоборот добилась успеха. Вопрос менять стратегии или не менять ? Ведь это может быть как началом новой тенденции (не путать с трендом/флетом !), так и случайностью. Т.е. получается что сам такой тестер будет иметь по крайней мере один (и важный !!!) настраиваемый параметр - период оценки и оптимизации. Не пойми, что я говорю о невозможности такого подхода. Я просто говорю что во всём этом есть свои трудности и туманные места.

Давайте всё-таки попробуем с простого.
Задача: можно ли написать функцию, которая раз в сутки прогоняет месячную историю и за параметр стоплосса ставит оптимальное число?
И САМОЕ ГЛАВНОЕ: можно ли с этой функцией проверять на тестере? Будет ли вообще тестер работать? Получается что каждые сутки в режиме теста он должен менять параметр стопа на новый день? Возможно ли это? Если решить эту задачу, остальное как уже сказали - глазурь.

Насколько я знаю подобную функцию тестера написать на mql можно, но задача эта для меня не простая так как я "программист любитель" и мне требуется время что-бы это сделать.
 

Самонастраивающиеся индикаторы - это тупиковое направление. Попробую обосновать мое мнение.
Я разработал несколько таких индикаторов, но они оказались чувствительны к волатильности котировок, поступающих из разных ДЦ. Т. е. эти индикаторы отлично работают на данных одного ДЦ и совсем не работают на данных другого. Хуже всего работают на данных НС. Усредненное движение котировок в ДЦ одинаковое, а волатильность различается, что сбивает индикатор с толку. Например, даже на стандартных индикаторах на одном и том же интервале котировок в одном ДЦ дивергенция есть, а в другом - нет.
Мои исследования показали, что именно волатильность является ведущим фактором, который должен учитываться в самонастраивающемся индикаторе. Однако, в итоге индикатор становится зависимым от способа фильтрации котировок в разных ДЦ и от изменения этого способа (о чем ДЦ не уведомляет).
Здесь я также столкнулся с тем, что "загрубить" (о чем все время говорит Ренат) самонастройку нельзя, поскольку она является постоянной (линейной), а не дискретной.

Полагаю, что уйти от проблемы волатильности можно только отказавших от учета абсолютных значений индикаторов и котировок. Т.е. для принятия решения в МТС следует использовать соотношение значений в том или ином виде, а это уже по сути распознавание образов.



 
ArtemRG
оно!
 
ArtemRG:

Самонастраивающиеся индикаторы - это тупиковое направление. Попробую обосновать мое мнение.
Я разработал несколько таких индикаторов, но они оказались чувствительны к волатильности котировок, поступающих из разных ДЦ. Т. е. эти индикаторы отлично работают на данных одного ДЦ и совсем не работают на данных другого. Хуже всего работают на данных НС. Усредненное движение котировок в ДЦ одинаковое, а волатильность различается, что сбивает индикатор с толку. Например, даже на стандартных индикаторах на одном и том же интервале котировок в одном ДЦ дивергенция есть, а в другом - нет.
Мои исследования показали, что именно волатильность является ведущим фактором, который должен учитываться в самонастраивающемся индикаторе. Однако, в итоге индикатор становится зависимым от способа фильтрации котировок в разных ДЦ и от изменения этого способа (о чем ДЦ не уведомляет).
Здесь я также столкнулся с тем, что "загрубить" (о чем все время говорит Ренат) самонастройку нельзя, поскольку она является постоянной (линейной), а не дискретной.

Полагаю, что уйти от проблемы волатильности можно только отказавших от учета абсолютных значений индикаторов и котировок. Т.е. для принятия решения в МТС следует использовать соотношение значений в том или ином виде, а это уже по сути распознавание образов.



Позволю себе несколько не согласится с утверждением - "Самонастраивающиеся индикаторы - это тупиковое направление". Хотя в остальном пожалуй согласен. Просто я считаю что может быть множество решений одних и тех-же задач. Например на вопрос: - "загрубить" (о чем все время говорит Ренат) самонастройку. - я нашел немного другое решение, а именно не загрублять значения индикаторов, а использовать фильтры которые позволяют снизить уровень "шумов".
 
Можно я сделаю маленькую подсказку? :)

Для любой системы важны не значения цены, а скорость ее изменения (иногда просто знак).
Иногда используют ускорение цены (оценка силы действующей на цену, как опережающий индикатор).
ВСЕ индикаторы используемые с МТС фактически предназначены для оценки скорости.
Разные индикаторы - это просто разные ВАРИАНТЫ оценки скорости.

1. ВСЕ осциляторы оценивают скорость, иногда ускорение (как MACD).

2. ВСЕ скользящие средние НИКОГДА не используются сами по себе,
только в сравнении с другими скользящими (цена - это мувинг с длиной = 1).
Это сравнение скользящих (фактически сравнение их разности с нулем) - это осцилятор.

3. Рассматривать нужно не цену, а логарифм цены.
В логарифмах все становится проще и правильнее.
При малых изменениях цены разницы между работой с ценой и логарифмом не будет,
при больших изменениях цены разница будет существенно.
 
Mak писал (а):
Можно я сделаю маленькую подсказку? :)

Для любой системы важны не значения цены, а скорость ее изменения (иногда просто знак).
Иногда используют ускорение цены (оценка силы действующей на цену, как опережающий индикатор).
ВСЕ индикаторы используемые с МТС фактически предназначены для оценки скорости.
Разные индикаторы - это просто разные ВАРИАНТЫ оценки скорости.

1. ВСЕ осциляторы оценивают скорость, иногда ускорение (как MACD).

2. ВСЕ скользящие средние НИКОГДА не используются сами по себе,
только в сравнении с другими скользящими (цена - это мувинг с длиной = 1).
Это сравнение скользящих (фактически сравнение их разности с нулем) - это осцилятор.

3. Рассматривать нужно не цену, а логарифм цены.
В логарифмах все становится проще и правильнее.
При малых изменениях цены разницы между работой с ценой и логарифмом не будет,
при больших изменениях цены разница будет существенно.

а может еще и примите участие в написании кода? :-), с вашим опытом программирования дело пошло-бы гораздо быстрее!