торговая стратегия на базе Волновой теории Эллиота - страница 291

 
Сергей, дело ведь не в возможности покритиковать Ваши результаты, а в том, иллюстрируют они что-либо или нет. Чтобы это понять надо иметь базу, фундамент от которого можно было бы оттолкнуться. Если этот промежуточный результат может продемонстрировать какое-то стат. преимущество, то большего и не надо. Все дальнейшее может это преимущество усиливать. Если же такого преимущества нет, то что тогда оценивать ?

А в данном случае условия эксперимента не дают возможности считать эти результаты подтверждением наличия стат. преимущества.


Ок.

«SL<MO» что такое MO?

И еще такой вопрос, как оптимизировать SL, хотя бы в двух словах? Обозначить его, как внешний параметр, т.е. один SL на все сделки?
 
Сергей, то что я написал - это не критика. Прочтите мой предыдущий пост.
Мысль только одна - по этим результатам трудно судить, не те условия эксперимента.
Новые результаты еще менее показательны. Нет ведь никакой статистики !
Из 21 месяца тестирования 10 - пересиживание.

Вы ведь не претендуете на то, что Ваша система не ошибается. Так поставьте стоп 20 и посмотрите, что будет. По крайней мере появится статистика.

И не относитесь к тому, что мы тут пишем, как к критике торгующего советника. И вообще как критике.

Кстати, переход ко всем тикам привел к уменьшению МО с 38 до 23. Это неплохой результат.
Интересно было бы также сравнить эти же показатели, но при наличии стопов в обоих случаях.

МО - мат. ожидание выигрыша.
Оптимизировать SL можно очень просто. Выведите его как внешний параметр и в тестере проведите оптимизацию, задавая пределы и шаг. Естественно, в коде эксперта надо добавить условие закрытия сделки при падении цены ниже SL для buy и наоборот для sell.
 

Сергей, то что я написал - это не критика. Прочтите мой предыдущий пост.
Мысль только одна - по этим результатам трудно судить, не те условия эксперимента.
Новые результаты еще менее показательны. Нет ведь никакой статистики !
Из 21 месяца тестирования 10 - пересиживание.


Юрий, я совершенно не нахохлился, не обиделся и все совершенно нормально. :о)))) В MathCADе нет 10 месяцев пересиживания, потому, как там есть код, который не позволяет заключать подобные сделки, но по другим соображениям. С точки зрения модели, 10 месяцев высиживания – это не ошибка. Для модели ничего «страшного» не произошло – цена сидела в канале (болталась с краюшку). Кстати, из-за таких случаев начал пытаться прогнозировать саму траекторию.


Вы ведь не претендуете на то, что Ваша система не ошибается. Так поставьте стоп 20 и посмотрите, что будет. По крайней мере появится статистика.


Не претендую, хотя пока и не нашел явных ошибок – в период жизни канала цена проходит расчетный уровень. Но наверняка, они рано или поздно появятся, тут у меня никаких иллюзий нет, слабые места в модели конечно есть.

Возможно, отклонюсь от своего плана и реализую стопы. По-прежнему надеюсь на вашу консультацию, ибо смотрю сейчас на MT, как неандерталец на калькулятор. В маткаде то все просто – формулы как они есть. :о)
 

Возможно, отклонюсь от своего плана и реализую стопы. По-прежнему надеюсь на вашу консультацию, ибо смотрю сейчас на MT, как неандерталец на калькулятор. В маткаде то все просто – формулы как они есть. :о)


Спрашивайте, к Вашим услугам.

А для меня наоборот. :-))
Впрочем, сейчас я смотрю не на маткад, а на матлаб. И уже не как неандерталец, а как кроманьёнец.
 
to grasn
Ещё 2 момента:
- В принципе нормально ожидать корреляцию между временем удержания позиции и величиной профита. На малых временах она вроде есть (на глаз, могу ошибаться). Но на более длинных (опять же "на глаз") ситуация выглядит более случайной. Но случайно должны случаться как небольшие плюсы, так и небольшие минусы. А минусов нет. Нет ли случайно в коде "юстировки" выходов?
- Практически любая стратегия имеет периоды "применимости" и "неприменимости". Если пересиживание маскирует период "неприменимости", то введение стопов может обернуться катастрофой для отчёта. А невведение - катастрофой для реального счёта.
 
Rosh
Должен пересчитать. Не в первый раз - так во второй. Можно посмотреть как это происходит на видео - https://www.mql5.com/zh/forum/103424

То есть идёт автоматический пересчёт? Но, насколько я понял, синхронизация котировок с временем брокера не предусмотрена. Хорошо если речь идёт о сшивании двух длинных кусков, тогда скачок времени на стыке, скажем на час, принципиального значения иметь не будет. А если исходная история представляет собой набор кусков и загрузка котировок заполнит дыры? Хорошенькая получится смесь.
Сам-то я правда загрузив историю сразу перебросил её в автономный терминал и ни с чем не смешивал.
 
to Gorillych


Всё равно непонятно. 14-я сделка прожила 20 минут, 15-я мучалась 10 месяцев. Почему в 15 сделке канал показал SELL, а не BUY?


Решил немного расширить ответ. Ниже на картинке сбор статистики времени жизни каналов (eurusd, часы), выполненный следующим образом: фиксируется длина канала, двигаемся вместе со временем, для каждого «текущего» бара строится канал фиксированной длины и оценивается время его существования (путем подсматривания будущего, разумеется). Попутно собирал всякие дополнительные параметры каналов. В данном конкретном случае канал имеет длину 300 отсчетов.



В красоте, конечно, уступает картинкам вейвлет преобразования, но обратите внимание на саму форму кривой (она сохраняется для других периодов и котировок), канал практически сразу занимает устойчивое положение, т.е. сначала следует пик, а потом продолжительность убывает, а не наоборот, хотя логичнее ожидать именно такую картину. Видно, что некоторые каналы живут довольно долго, около 3.5 своей длины (напомню, что при подсматривании будущего, параметры канала не меняются). Так вот, я не знаю, как сложится траектория цены за это время, но практически наверняка во время существования канала, цена пройдет рассчитанный уровень, если конечно, дополнительные критерии сработают, в том числе и показатель Херста. Это может произойти за 20 минут, может произойти за несколько дней, за несколько месяцев. Конечно, это одна из неприятных особенностей – или верить или отказываться от сделки или допускать убыток. Аналогичных особенностей по степени «неприятности», можно найти достаточное количество в любых других стратегиях и моделях.

В этой модели я не ищу разворотную область (для этого предназначены другие модели). Код ядра модели в MathCAD занимает несколько строчек, а код, который блокирует 10 месячные сделки, занимает несколько сотен строк. Так вот, первые тестирования этой модели давали 20% убыточных сделок (после блокирования), теперь в MathCAD их уже 2%, остается выяснить, что будет в MT.

Кстати, форма кривой сама по себе полезна. Если Вы соберете статистику (возможно, уже собирали), то сможете классифицировать экстремумы (либо на основе здравого смысла или прибегая к профессиональным системам), а посмотрев около текущего отсчета ее форму (отступая каналом на шаг назад), сможете с высокой степенью достоверности оценить время существования канала.

А вообще, в каналах таится огромный смысл …, но это уже совсем философия.

to Candid

to grasn
Ещё 2 момента:

- В принципе нормально ожидать корреляцию между временем удержания позиции и величиной профита. На малых временах она вроде есть (на глаз, могу ошибаться). Но на более длинных (опять же "на глаз") ситуация выглядит более случайной. Но случайно должны случаться как небольшие плюсы, так и небольшие минусы. А минусов нет. Нет ли случайно в коде "юстировки" выходов?

- Практически любая стратегия имеет периоды "применимости" и "неприменимости". Если пересиживание маскирует период "неприменимости", то введение стопов может обернуться катастрофой для отчёта. А невведение - катастрофой для реального счёта.


Ровно по той причине, что еще рано (тест философский) я вилял как маркитанская лодка, когда Юрий припер меня SL-ом к стенке. И таки практически уговорил добрым словом и пистолетом ввести SL. :о)
К слову сказать, ранее я не использовал стопы в лоб, как параметр ордера, а реализовывал это через контроль открытой позиции, потому как условия всегда меняются, и в дальнейшем намериваюсь этому придерживаться.

to Yurixx

Юрий, прошу вашей помощи с SL. :о)

Как писал ранее, никогда не использовал SL, а пользовался динамическим контролем ордера. Возможно, это не очень удобно, потому как система все время должна быть подключена к серверу, но, на мой взгляд, это более разумно.

Смутно помню, что были у меня какие то проблемы с SL (а было это около год тому назад), то ли ДЦ не позволял их ставить слишком далеко, то ли еще чего. Короче, посмотрел документацию и «вспомнил», что это уровень цены, при котором ордер закрывается. Ок, сказал я себе и ввел следующие параметры для SL в зависимости от типа ордера:

Bid-20*Point
Ask+20*Point

Ни одной сделки, сейчас пытаюсь понять почему, вернее запросить код ошибки. Ввел еще несколько вариантов – опят сделок нет. В итоге мне это надоело, и я указал уровень цены SL в лоб 20.0, заработало:



Как в том мультике «ничего не понимаю». Юрий, объясните динозавру, как их правильно ставить, и почему значение, скажем 1.2 хуже 20.0
 
Привет, Сергей !

1. Можно не ставить SL вообще, а самостоятельно динамически контролировать уровень цены и "закрывать" сделку в нужном случае. Это ведь все символика, а не торговля. Всего лишь сбор статистики. Но в этом случае все надо делать своими руками, а не пользоваться тестером. То есть надо просто написать скрипт, который пробегает по истории реализуя стратегию и собирая результаты в файл. Ничего сложного в этом нет, так как 95% этого скрипта - это и есть текст Вашего советника.

2. Если пользоваться тестером, то SL надо ставить в выставляемых ордерах так, как это и делается в реале. Из того, что Вы написали я так и не понял, в чем собственно проблема. Проще всего - вырежте куски кода, где Вы объявляете, определяете и используете SL и приведите их здесь. Возможно проблема в нормализации (все цены в ордерах должны быть нормализованы, т.е. округлены до точности Point). Кстати, если Вы в явном виде указали 20.0, то это как раз и есть нормализованное значение. А 20*Point - нет. Если бы Вы поставили в явном виде 1.2, то это тоже сработало бы (для buy). Попробуйте так:

Bid-20.0*Point
Ask+20.0*Point

Однако, повторюсь: Bid,Ask оказывается тоже могут быть ненормализованы.
 

1. Можно не ставить SL вообще, а самостоятельно динамически контролировать уровень цены и "закрывать" сделку в нужном случае. Это ведь все символика, а не торговля. Всего лишь сбор статистики. Но в этом случае все надо делать своими руками, а не пользоваться тестером. То есть надо просто написать скрипт, который пробегает по истории реализуя стратегию и собирая результаты в файл. Ничего сложного в этом нет, так как 95% этого скрипта - это и есть текст Вашего советника.


Я так и собираюсь делать, что называется, как всегда.


2. Если пользоваться тестером, то SL надо ставить в выставляемых ордерах так, как это и делается в реале. Из того, что Вы написали я так и не понял, в чем собственно проблема. Проще всего - вырежте куски кода, где Вы объявляете, определяете и используете SL и приведите их здесь. Возможно проблема в нормализации (все цены в ордерах должны быть нормализованы, т.е. округлены до точности Point). Кстати, если Вы в явном виде указали 20.0, то это как раз и есть нормализованное значение. А 20*Point - нет. Если бы Вы поставили в явном виде 1.2, то это тоже сработало бы (для buy)


Проблема в том, что выдает код ошибки 130 – неправильные стопы. :о)

Как все хитро. А есть ли какая функция, которая просто округляет число до 4 знаков после запятой?
 
grasn
Так вот, я не знаю, как сложится траектория цены за это время, но практически наверняка во время существования канала, цена пройдет рассчитанный уровень, если конечно, дополнительные критерии сработают, в том числе и показатель Херста. Это может произойти за 20 минут, может произойти за несколько дней, за несколько месяцев.

То есть за время выдержки той 10-месячной сделки(при такой просадке) канал не разрушился? Мощщный канал был, однако :)

grasn
Ок, сказал я себе и ввел следующие параметры для SL в зависимости от типа ордера:

Bid-20*Point
Ask+20*Point

Ни одной сделки, сейчас пытаюсь понять почему, вернее запросить код ошибки.

Посмотрите журнал, если не срабатывает OrderSend, там делается запись о причине.
Причина обращения: