Суровая статистика

Если гора не идет к Магомету, то ... ну ее на хрен!

Евгений, в основном, для Вас и Quod Licet (он просил картинок) открыл тему в Волновом анализе.
Доживем до понедельника

 

Немного не так. Где-то уже писал. Повторю здесь. Если б в самом начале была поставлена задача сделать в ZUP то, что получилось сейчас, то скорее всего ничего сделано не было бы. Необходимо начинать с малого. Главное в самом начале - сделать правильный скелет, а мясо потом нарастет. ^secret^

 

Да нет, вы все верно поняли. Я говорил и о точках C, и о точках D-разворота, предлагая некий выбор - что проще реализовать, то и хорошо на первых порах. Как раз поэтому я говорил о малополезности узких постановок - тут есть некий "люфт" в ту или иную сторону, в зависимости от того, сложно ли это добавлять в индикатор или нет, и нет ли подводных камней типа того, что "график подстраивается под бабочку", который может исказить анализ.

В идеале важен анализ и точек C, и точек D, они дают нам разную взаимодополняющую информацию.

* Анализ точек C
дает нам информацию о луче CD. Бытовое понимание пятиточечных паттернов - в том, что "где-то в районе прямоугольника тренд развернется". Т.е. мы можем построить "простой зигзаг" от точки C, посмотреть соотношение AB и СD, и на гистограмме мы вправе ожидать всплеска в районе фибо. Возможно, нескольких всплесков в точных фибо от XD и от AB. Возможно, всплеска на "ближней границе прямоугольника". В идеале гистограмма должна построить нам аналог "красного прямоугольника", только уже на стат.основе - "здесь тренд прекращается чаще".

* Анализ точек D
дает нам информацию о луче DE, т.е. о ходе отработки паттерна. Здесь мы ожидаем уже не всплеска на гистограмме соотношений, а повышенного МО (=удлиненных трендов от точки D). Мы можем использовать как D-точки "ближнюю и дальнюю" границы прямоугольника, а также точки, которые мы получили на преыдущем этапе "анализа точек С". (мы не имеем права брать реальную D-точку зигзага, поскольку она построена искусственно, "задним числом")

Где-то так. Т.е. и то, и другое интересно и может привести к стат.значимым выводам.

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

 

Если паттерн удалится с графики и прямоугольник также удалится с графика. Это происходит в том случае, если рынок идет в сторону увеличения луча CD и без откатов пересекает дальнюю сторону прямоугольника.

Паттерны, найденные с помощью ZUP, привязаны к зигзагу. И в этом имеется отрицательный момент. Это понимание пришло только сейчас, в момент написания этих строк. Привязка к зигзагу несколько механически отражает "истинное положение дел на рынке". Например, такая механическая привязка не учитывает временнЫх параметров рынка, не учитывается должным образом развитие рыночных процессов во времени. Бабочки кроме ценовой составляющей имеют также и определенные временные рамки для своего развития. В ZUP сейчас реализована с помощью зигзага только ценовая составляющая.

 

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

более или менее некстати - просто пользуюсь случаем, чтобы вставить картинку по временным корреляциям. Это соотношение "временнОй продолжительности" соседних лучей "простого зигзага" для фунта 20 (похожая картинка для фунта больших размеров). По горизонтали - время развития текущего луча, по вертикали - время развития предыщущего.



Т.е корреляции практически нет, круг практически ровный. Следующий луч развивается вне зависимости от времени развития одного луча. Это не доказательство отсутствия корреляций времени вообще - просто самый первый шаг. Какая-то скошенность "слева-направо сверху-вниз" на грани иллюзии все же присутствует (и не забудем, что скорость, в отличие от времени, коррелирует значительно сильней - см. одну из первых страниц)


<b>2 gorillych</b>: спасибо за приглашение, в тему, конечно, загляну, но что касается картинок, то в принципе, обезьяна как иллюстрации "неудавшейся пятой" для меня полностью хватило ))).

 

Это уже должна быть специальная разработка. Специальная для тестирования. Сложно со временем. Разорваться на части нет возможности.

 

<b>2nen:</b>

Понятно, ок. (хотя вроде бы Вы прикидывали даже возможность встроить в зигзаг целую выгрузку csv - а это сложнее)))))


<b>2all:</b> да, кстати про csv - если кому-то скрипт для выгрузки "базового csv (время, длины-расстояния и т.п)" из зигзагов нужен - отпишитесь, я свой адаптирую и выложу


<b>2nen:</b>

ЗЫ: По поводу "Интересно сделать статистические исследования зигзагов в следующем разрезе." - да, я посмотрю, как это можно оцифровать.

ЗЫ2 (вникая) "Момент, когда тренд вниз фиксируется зигзагом проявляется в момент появления луча, направленного вниз" - это вот как раз "момент определения вершины", о котором мы с koy говорили. Скрипт не может узнать этот момент по "моменту появления луча", т.к. собирает информацию уже с истории, где все лучи есть. Так что как раз тут тоже увы - без "событий" никак.

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

ЗЫ3: У меня похожая тема с разными зигзагами в загашнике лежит, и я постараюсь собрать статистику по своему индикатору, который такую информацию дает. Но там только "простой зигзаг", с откатом в пунктах.

Хотя тут вопрос:

"Допустим, закончился главный тренд вверх. Рынок показал максимум. Далее начинается тренд вниз. Момент, когда тренд вниз фиксируется зигзагом проявляется в момент появления луча, направленного вниз. Далее по мере развития тренда луч перерисовывается, увеличивая свою длину. Отрезок времени от момента первого появления нового луча и до момента окончания развития этого луча, то есть до момента окончания тренда, обозначим X. Приращение цены за время X обозначим Y."

Вы в начале описания говорите о вложенных зигзагах разных размерностей, но больше нигде второй зигзаг не встречается. Ежели он где-то присутствует - опишите, пожалуйста, чуть подробней. Если речь о поведении зигзага после "фиксации" его вершины - то это постановка, аналогичная той, которую здесь предлагал Koy на прошлой странице, и которую я вкратце комментировал (пример о 50-пунктовой пиле и т.п). При первом и втором взглядах там ничего интересного не обнаруживается. Средняя "ЗЗ-волатильность" 2N не дает нам заработать ни при торговле по тренду, ни против. Равновероятно, что после любой текущей точки цена пойдет вверх, или вниз. Основная причина именно в том, что "момент, когда тренд фиксируется" - вещь искусственная.

(но это опять же - только для простого зигзага. Как будет с трендовыми - не знаю, самому интересно )))

 

<b>2gorillych</b>

В тему заглянул, спасибо, любопытно, буду мониторить, я тут по поводу тамошнего: "Разметка задним числом не убеждает в возможности метода прогнозировать" - я там на прошлых страницах говорил тоже о "Задним числом можно перестроить график так, что фибо будет много" - на всякий случай уточню, что не имел в виду ничего крамольного/некорректного типа "сидят эллиотчики в тайной комнате и перерисовывают свои разметки за 98 год как покрасивше, чтобы продать потом мне книжку", а имел в виду следующее:

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

Т.е. если в пределах этого "скользящего окна"-континуума мы видим два экстремума, и второй нам показался более "значимым", мы можем отказаться от первого в пользу второго. Т.е. "задним числом". И если мы значимость определяем в том числе и по фибам, то в финальном зигзаге у нас окажется бОльшее количество фибо, чем положено по статистике.

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

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

По такому зигзагу, как и по волновой разметке, говорить о существовании фибо на рынке будет некорректно. Но, возможно, он позволит зарабатывать, а это важнее )))))).

 

А вот это сделать необходимо. Здесь стоит поработать. Этим и займемся. Это приоритетное направление.

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

Даже в ZUP можно организовать под это дело два буфера. Это дополнительно к трем буферам, задействованным под зигзаг. Первый буфер с точками зигзага. Второй - с минимумами зигзага. Третий - с максимумами зигзага.

Другой вопрос - не все алгоритмы зигзагов поддаются такой обработке. На данный момент так видится.

Достаточно ли будет информации в двух дополнительных буферах?

 

В этой теме некоторое пересечение с идеей koy имеется. У него предлагается провести исследование для зигзагов на одном таймфрейме. У меня для зигзагов, построенных на разных таймфреймах.

Точнее, я предлагаю исследовать всего один зигзаг. Для начала - на одном таймфрейме. А именно - только значение величины <b>X</b> - время развития луча после фиксации тренда. И уже зная характеристики параметра <b>X</b>, можно далее подумать, как на участке времени <b>X</b>, торговать на откатах на меньших таймфреймах.

 

Хех, приятно видеть такое оживление ))). Я, честно говоря, не вижу, почему бы это направление было более приоритетным, чем паттерны ))) (вероятно, потому, что в "точках подтверждеия" я уже копался достаточно много, и мне они уже более-менее неновы и я там чего-то драматического не ожидаю - хотя чем черт не шутит) - но раз вам они нравятся, я не против )).

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

* Объекты значительно универсальней. Они реализуют абстрактную парадигму "события", и могут быть элементарно расширены не только для хранения события "луч появился", но и для других, типа "цена пересекла" (соответственно, их можно более единообразно собирать для csv)

* Буферы имеют свойство исчерпываться, их всего восемь. Объекты - нет. Объекты могут быть расположены в одной точке, если там случается два события.

* Объекты, которые не висят "через бар", а хоть чуть реже, расходуют меньше памяти, чем доп.буфера.

* Объекты более "отчуждаемы" от основного кода индикатора - достаточно закомментить кусок с созданием объектов, и индикатор возвращается в первозданное состояние.

* Объекты не более трудоемки как для МТ-движка, так и для создания в коде индикатора.

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

Для ускорения сбора статистики можно предусмотреть гибридную схему - существует один буфер, в котором среди EMPTY_VALUE встречаются значения N, и при просмотре буфера по этим значениям ищутся объекты (чтобы избежать частого поиска) - но вообще это непринципиально, там расходы копеечные.

Если все же вы остановитесь на буферах - в моем текущем индикаторе сейчас в одном буфере лежат точки "время-цена", а во втором - флаги "1" для вершины и "-1" для дна (такая схема расширяема для других событий, хотя и не так хорошо, как объекты) - но, в общем, это все равно - как удобней, так и делайте.

 

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

Опять получается, что много разных идей скопилось. Не к добру это. Когда слишком много - первый признак, что ничего сделано не будет.

 

И я о чем!) Мы же не собираемся хранить эти данные в секрете? Для любого человека ничуть не сложней написать

if (ObjectFind("zup_stat"+time)) { create csv }
чем
if (iCustom() != EMPTY_VALUE) { create csv }

Объем знаний "в буфере 5 хранятся точки подтверждения вершин"
опять же примерно равен
"в объектах zup_stat_TIME хранятся точки подтверждения вершин".

Я просто пока не улавливаю, почему буфера более универсальны - с моей т.з строго наоборот.

<b>(переходим в режим чата, я чувствую - отправил ответ, а у вас сообщение уже дополнено)</b>

идей-то не много - строго одна, простая-тупая, про точки подтверждения. Иконки выглядят дружелюбно, стрелочки вверх - подтверждена точка вверх, стрелочки вниз - вниз. Все довольны ))).
Про пересечение и прочее потом добавим, если сможем/захотим. Сейчас - минимум.

две строчки кода в индикатор добавляются, прямо после обнаружения вершины

if (stats_enabled) {
int arr_code; if (is_up) arr_code = ARROW_UP; else arr_code = ARROW_DOWN;
ObjectCreate("zup_stat"+curtime,OBJ_ARROW,0,curtime,curprice)
ObjectSet(name,OBJPROP_ARROWCODE,arr_code);
}

(пишу без заглядывания в код, с синтаксисом навру)

 

Не все так просто. У разных зигзагов по разному будет. У некоторых зигзагов для обнаружения вершины код можт быть сравнимым по объему, с кодом самого зигзага.

С одной стороны, конечно, проще объекты создавать. С другой стороны, имеется торговая система, в которой эти точки используются. И удобнее точки хранить в буфере, чтобы выводить на график и обрабатывать их универсальнее через буфер. Сейчас как раз такую систему тестирую в режиме ручной торговли при тестировании. Результаты хорошие. Это предполагает и при "не интересных результатах статисследования" хорошие возможности для торговли с помощью новой функциональности индикатора. Но описания торговой системы не будет. Каждый волен применять новые возможности сообразно своей фантазии.

 

так он и так и сяк будет, хоть в буферах хранить, хоть в объектах. Хуже того - он уже есть )))), этот код. Иначе бы индикатор не работал.

добавить нужно только две строчки ))

 

ну бог с вами )), если система есть, и уже какие-то планы по дальнейшему использованию этих буферов - делайте как удобней ))

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

я-то полагал, что мы говорим о сборе статистики, а для сбора собирать то так, то сяк, то из одних буферов, то из других - это как раз неуниверсально.

но, повторюсь - раз у вас есть далеко идущие задумки - то делайте согласно им.

 

Объекты при необходимости добавить всегда можно.

На сегодня хватит. Искорку неплохую высекли...

 

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

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

К чему это?

Я боюсь, что как-то не срастается диалог - уже который раз вы не понимаете меня, а я вас. Вам мои идеи кажутся непонятными, мне вот такие особенности, которые периодически возникают у вас в общении. Надо бы как-то это урегулировать, чтобы излишних трений не возникало.

 

<b>Quod Licet</b>
Попробуйте проверить корреляцию по времени для фунта с такими параметрами:
размерность ZZ 120 пунктов
Луч CD- от 12 до 50 часов
Луч СВ- до 100 часов
Луч ВА- до 48 часов

 

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