Отправлено: 29.11.13 09:19. Заголовок: Захват флэта

Захват флэта
Инструмент трейдера для торговли в канале горизонтального флэта.

Захват тренда
1. Разработана вторая версия советника "захват флэта", в которой добавлена возможность изменения некоторых параметров советника без его перезагрузки.
2. Разработана версия советника для торговли в трендовом канале.

 Отправлено: 26.02.14 19:26. Заголовок: Ок. Пока все правиль..

Ок. Пока все ПОЧТИ правильно.
НО!!!!!!!!!!!!!!!!

ЗАМЕЧАНИЕ №1.

Scriptong пишет:

цитата:

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

Ньюанс.
Сравниваем не на предыдущей свече смену положения быстрой б1 к медленной с0 , и сохранение этой смены при открытии текущей , а для первой свечи , при которой б1 зашла за с0 и последней свечи , при которой эта смена подтверждена.
Например , б1 зашла выше с0 на нулевой свече , а задержка задана в 3 свечи , то сравниваем нулевую свечу и эту 3-ю. Если при их завершении линия б1 выше линии с0 , то регистрируем пересечение КМА. Даже , если между ними были ситуации , когда линия б1 заходила под линию с0. Важно , что завершение нулевой свечи показало смену направления , а при завершении 3-й свечи новое направление подтвердилось.

ЗАМЕЧАНИЕ №2.

Вертикаль ПКМА рисовать на свече , которая является последней из сравниваемых.
То есть , в моменте произошло пересечение б1 и с0 ( переворот ПКМА ). Свеча , на которой этот переворот зафиксирован , является 0 свечей. И нам важно , что при завершении этой свечи имел место переворот ПКМА. Это первая свеча к сравнению.
Если задана в параметрах "Задержка регистрации пересечения..." =3 , то после 0-й свечи смотрим на 3-ю свечу. Если при ее завершение направление переворота ПКМА сохраняется с тем , что зафиксировано при завершении 0-й свечи , то имеем факт переворота КМА.
И НА ЭТОЙ СВЕЧЕ отрисовывается вертикаль. Не на следующей ( 4-й ) , а именно на свече , которая подтвердила при завершении новый переворот МАшек ( ПКМА ).

ЗАМЕЧАНИЕ №3.

Думаю , что можно оставить расцветку пересечения ПКМА. Так , как есть сейчас : цветное и пунктирное. Смотрится легко и понятно. То есть п.4 поста темы от 19.12.13 17:25 читаем , как:
"4. Пересечения КМА сопроводить штрих-пунктирной вертикалью белого цвета того направления , который задается в моменте пересечения МАшками б1 и с0 , где линия б1 - главное ( определяющее ) направление."
То есть линия б1 - главное направление. Линия с0 - подчиненное направление. Что означает: Выход б1 выше с0 дает направление ВВЕРХ и голубую пунктирную вертикаль. Выход б1 под с0 дает направление ВНИЗ и розовую пунктирную вертикаль.
( Единственное - потом , когда будем выделять 0-ПКМА , усилим отображение этой вертикали путем перерисовки пунктира на сплошную вертикаль - но это потом. )

Сейчас же имеем ситуацию наоборот , что неверно. Я об этом еще в посте 06.02.14 00:05 писал.

То есть надо переписать ( перевернуть на обратно ) параметры i_upCrossLineColor и i_dnCrossLineColor.

На ниже-приведенных картинках это отчетливо видно: выход б1 выше с0 отражается красным , а надо синим.
То есть б1 , как более быстрая МАшка раньше показывает направление движения относительно менее быстрого с0 , несмотря на другой период. И присвоение цвета следует за линией б1. Потому линия б1 должна задавать цвет вертикали.
То есть НАДО:
Выход б1 выше с0 = голубая пунктирная вертикаль ( б1 пересекает с0 "снизу вверх" , то есть смена движения ВВЕРХ ) , а
Выход б1 ниже с0 = розовая пунктирная вертикаль ( б1 пересекае с0 "сверху вниз" , смена движения ВНИЗ ).
То есть направление определяется тем откуда и куда пересекает быстрая линия б1 медленную линию с0.

На рисунке №1 = это то , как реализовано сейчас. На рисунке №2 = то , как должно быть ( здесь б1 - красная сплошная , с0 - желтая , пунктирная ):






П.С.
Не знаю , есть ли разница в том пересечение какой МА относительно другой МА отслеживать для цели фиксации пересечения ( может быть как-то влияют разные периоды машек ) , но если есть такое влияние , то можно оставить текущий принцип ( как это сейчас реализовано в индикаторе ) , когда за главную линию принята с0 , а подчиненная б1 и это находит отражение в параметрах i_upCrossLineColor и i_dnCrossLineColor.
Но , в этом случае , тупо заменить i_upCrossLineColor на i_dnCrossLineColor , а i_dnCrossLineColor на i_upCrossLineColor.
( попробую пояснить , что имел ввиду ( если не совсем понятно ) :
МАшка с0 , хотя и медленная , но в текущем периоде более подвижна чем б1 , которая хоть быстрая , но старшего периода. А посему она ( с0 ) отрисовывается каждые 15 мин. , а б1 только каждые 60 минут. И здесь может быть некий конфликт , когда б1 отстает от с0 . Возможно , я не прав и б1 также пересчитывается каждые 15 минут - в этом случае все нормально. )

ЗАМЕЧАНИЕ №4.


Надо сделать так , чтобы вертикали одного цвета сменяли друг друга последовательно. А последовательные одноцветные вертикали игнорировались. То есть голубая сменяет розовую далее голубая и опять розовая.....
Если имеем голубую вертикаль , а следующая тоже голубая , то эта ( следующая ) игнорируется. Следующая отражается только вертикаль противоположного направления.
Логика: смена ПКМА - смена направлений. Текущее направление не может быть сменено на такое же направление. Это нонсенс.
Обратного направления вертикаль показывает , что имеем новый перелом ПКМА обратного направления.
Это недоразумение связано с тем , что возникают случаи , когда б1 на 1-2 текущие свечи зашла в обратном направлении , но не подтвердилась и вернулась обратно , не активировав новый переворот КМА.
Но при этом индикатор засек , что б1 зашел за с0 , подав ложный сигнал. А возврат в прежнюю область тем не менее фиксирует вертикалью , поскольку отвечает на ложный сигнал. И эта вертикаль того же направления , что и ранее было.
А нам этого не надо: цветность вертикалей должна чередоваться последовательно и ложные заходы не должны генерировать ложные же вертикали , повторяющие направление последнего неложного переворота ПКМА.
На рисунке №3 этот момент я обвел эллипсом:

 Отправлено: 05.03.14 15:10. Заголовок: ko_ko пишет: Сравни..

ko_ko пишет:

цитата:

Сравниваем не на предыдущей свече смену положения быстрой б1 к медленной с0 , и сохранение этой смены при открытии текущей , а для первой свечи , при которой б1 зашла за с0 и последней свечи , при которой эта смена подтверждена. Например , б1 зашла выше с0 на нулевой свече , а задержка задана в 3 свечи , то сравниваем нулевую свечу и эту 3-ю. Если при их завершении линия б1 выше линии с0 , то регистрируем пересечение КМА. Даже , если между ними были ситуации , когда линия б1 заходила под линию с0. Важно , что завершение нулевой свечи показало смену направления , а при завершении 3-й свечи новое направление подтвердилось.

Я не вижу разницы в своем описании и в Вашем.

ko_ko пишет:

цитата:

Вертикаль ПКМА рисовать на свече , которая является последней из сравниваемых. То есть , в моменте произошло пересечение б1 и с0 ( переворот ПКМА ). Свеча , на которой этот переворот зафиксирован , является 0 свечей. И нам важно , что при завершении этой свечи имел место переворот ПКМА. Это первая свеча к сравнению. Если задана в параметрах "Задержка регистрации пересечения..." =3 , то после 0-й свечи смотрим на 3-ю свечу. Если при ее завершение направление переворота ПКМА сохраняется с тем , что зафиксировано при завершении 0-й свечи , то имеем факт переворота КМА. И НА ЭТОЙ СВЕЧЕ отрисовывается вертикаль. Не на следующей ( 4-й ) , а именно на свече , которая подтвердила при завершении новый переворот МАшек ( ПКМА ).

То же самое.

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

P. S. Какой был смысл в смене ника, если содержание осталось то же?

 Отправлено: 06.03.14 04:48. Заголовок: Scriptong пишет: Я ..

Scriptong пишет:

цитата:

Я не вижу разницы в своем описании и в Вашем.

у тебя сравниваются комбинация б1 и с0 для свечи регистрации с предыдущей свечей.
Это можно принять , если предыдущая свеча = свече пересечения , а задержка регистрации =1.
Но если задержка регистрации=3 , то у тебя сравнивается комбинация б1 и с0 для этой , 3-й свечи , и предыдущяя. Что неверно.
Аналогично неверно , если задержка регистрации = 0 , тогда комбинации б1 и с0 сравниваются для свечи пересечения и предыдущей свечи? А какая комбинация может быть у предыдущей свечи относительно свечи пересечения? Конечно , другая.

ПОЭТОМУ надо сравнивать комбинацию б1 и с0 для свечи регистрации ( например , третью ) и свечи пересечения ( нулевая свеча ). В этом разница.
Если на свече регистрации имеем ту же комбинацию б1 и с0 , что и при свече пересечения , то переворот КМА СОСТОЯЛСЯ. Не взирая на то , что между этой свечей пересечения и свечей регистрации комбинации б1 и с0 могли меняться.
В этом случае , если задержка регистрации=0 , то сравниваем свечу пересечения и эту же свечу пересечения. Комбинация б1 и с0 для первой указывает на смену направления , а для второй на подтверждение этого изменения. Значит переворот СОСТОЯЛСЯ на первой же свече пересечения.


Это по ЗАМЕЧАНИЮ №1.


Теперь , что касается ЗАМЕЧАНИЯ №2.

Без лишних пояснений: вертикаль ПКМА , если переворот СОСТОЯЛСЯ , размечаем на свече регистрации ( если я правильно понял , какую свечу ты называешь свечей регистрации ).
Соответственно ,
Scriptong пишет:

цитата:

Минимальное значение параметра 0 указывает на регистрацию пересечения сразу же после открытия свечи, следующей за свечей пересечения.

В этом случае вертикаль ПКМА должна размечаться на свече пересечения. И свеча пересечения совпадает со свечей регистрации ( так? ).
При задержке =1 , при условии что переворот состоялся, вертикаль устанавливается на первой свече , следующей после свечи пересечения.
При задержке=3 , при условии что переворот состоялся , вертикаль устанавливается на 3-й свече , следующей после свечи пересечения.
И т.д....
Впрочем , похоже , так сейчас и реализовано. Если так , то все нормально. И замечание №2 не актуально.

по ЗАМЕЧАНИЮ №3.

По тому что сейчас реализовано , i_upCrossLineColor = это пересечение ВВЕРХ с0 линии б1. То есть в текущем индикаторе задано , что с0- главная линия , которая задает направление и цвет вертикали ПКМА ( голубой ).
НО!!!!!!!!!!!!
Главной же линией ДОЛЖНА считаться линия б1( быстрая ). И она задает направление и цвет.

Соответственно , цветность вертикалей на графике ДОЛЖНА быть сменена с точностью до-наоборот.


по ЗАМЕЧАНИЮ №4.

Смена ПКМА - это смена направлений. Не может быть смена голубого ( направление вверх ) сменяться на голубой ( направление вверх ).
Но сейчас такие вещи имеют место быть.
Это происходит потому что НЕСОСТОЯВШИЙСЯ ( не подтвержденный ) переворот КМА индикатором воспринимается , как истинный. Хотя вертикали не рисует ( пропускает ) , но сигнал сохраняется и индикатор отвечает на этот сигнал путем поиска нового пересечения , который оказывается того же направления.
Результатом является абсурдная отрисовка следом за голубой вертикалью тоже голубой ( или нескольких ) вертикали. То есть смены ПКМА по правилу задержки не состоялось , а на графике отмечается , что направление вверх сменилось направлением тоже вверх.
Резюме: ложные ( не подтвержденные ) перевороты КМА индикатор должен игнорировать.
Или по-другому: смена направлений ПКМА должна быть четко последовательной ( вверх-вниз-вверх-вниз-вверх... ) , а цветность вертикали должна четко последовательно меняться ( голубая-розовая-голубая-розовая-голубая..... ).
см. последний рисунок предыдущего поста.

 Отправлено: 05.03.14 15:46. Заголовок: попробуйте прочитать..

просто читай только выделенку .........
если не понятно , то читай остальное.

 Отправлено: 12.03.14 17:32. Заголовок: ko_ko пишет: просто..

ko_ko пишет:

цитата:

просто читай только выделенку ......... если не понятно , то читай остальное.

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

 Отправлено: 12.03.14 18:36. Заголовок: Scriptong пишет: В ..

Scriptong пишет:

цитата:

В таком тоне

В каком тоне?
Я учел твоё пожелание писать кратко. И написал , что если нет времени читать и вникать в текст , то достаточно прочитать только выделенку. В выделенке 4п.:
1. у тебя сравниваются комбинация б1 и с0 для свечи регистрации с предыдущей свечей. А надо сравнивать комбинацию б1 и с0 для свечи регистрации ( например , третью ) и свечи пересечения ( нулевая свеча ). В этом разница.
2. вертикаль ПКМА , если переворот СОСТОЯЛСЯ , размечаем на свече регистрации.
3. цветность вертикалей на графике ДОЛЖНА быть сменена с точностью до-наоборот.
4. ложные ( не подтвержденные ) перевороты КМА индикатор должен игнорировать.
Вот и все. Коротко и понятно.
Далее написал , что , если есть вопросы , то можно прочитать невыделенную расшифровку.
Возможно надо было так написать:

Scriptong пишет:

цитата:

просто читай только выделенку ...( если не понятно , то читай остальное ).

Тогда форма воспринимается по-другому? Чес-говоря , в такой форме и подразумевалась ремарка. Звеняюсь , что не до-оформил абзац.

Если же момент уважения-неуважения заключается в том , что я обращаюсь на "ты" , а не на "вы" , то , если посмотреть на прошлые посты , то я практически никогда не употребляю слово "вы". Лет уж 5 как или более. Поскольку слово "вы" = "вi" = "вiй"= бес. ( Иду на Вi = Иду на беса ( врага ) )
Бесом я тебя не считаю , потому на "вы" не называю , а просто на "ты".
Кстати сказать , в английском языке , который имеет много от древнерусского ( поскольку первые переселенцы были славяне ) есть только "ты". Что говорит о том , что когда славяне переселились в Европу , то никакого "вы" не было.
Впрочем , если желаешь , то могу называть тебя на "вы" ( вий , бес ). Правда язык не поднимается. Ну да ладно , на клаве пальцами выдавлю.

 Отправлено: 20.03.14 15:34. Заголовок: ko_ko пишет: Если ж..

ko_ko пишет:

цитата:

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

Просто существуют общепринятые правила. Толкование обращения друг к другу от Задорнова следует воспринимать именно так, как он сам себя позиционирует, т. е. как сатирик. Это не научная работа, признанная в русскоязычном обществе.

ko_ko пишет:

цитата:

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

Все равно не понимаю, что не так. Приведите пожалуйста объяснение в форме рисунка с разметкой номеров свечей.

ko_ko пишет:

цитата:

2. вертикаль ПКМА , если переворот СОСТОЯЛСЯ , размечаем на свече регистрации.

Исправлено.

ko_ko пишет:

цитата:

3. цветность вертикалей на графике ДОЛЖНА быть сменена с точностью до-наоборот.

Для этого программист не нужен, т. к. существуют настроечные параметры. Их значения легко изменить.

ko_ko пишет:

цитата:

4. ложные ( не подтвержденные ) перевороты КМА индикатор должен игнорировать.

Это так и было. Если нашли ошибку, то приведите конкретную ситуацию, чтобы я смог воспроизвести ее у себя.

Третья версия

 Отправлено: 20.03.14 17:34. Заголовок: Scriptong пишет: ko..

1.===============================
Scriptong пишет:

цитата:

ko_ko пишет:  цитата: 1. у тебя сравниваются комбинация б1 и с0 для свечи регистрации с предыдущей свечей. А надо сравнивать комбинацию б1 и с0 для свечи регистрации ( например , третью ) и свечи пересечения ( нулевая свеча ). В этом разница. Все равно не понимаю, что не так. Приведите пожалуйста объяснение в форме рисунка с разметкой номеров свечей.

Ок. Попробую.

Рисунок ниже имеет 2 вертикали: Первая ( V1 ) - прерывистая вертикаль , образованная индикатором версии №1. Вторая ( V2 ) - сплошная вертикаль , образованная индикатором версией №2. Разница между ними в том , что в версии V1 вертикаль рисуется по первому же сигналу переворота ПКМА , а в версии V2 мы задаем задержку для подтверждения.
В нашем случае задержка = 3. ( Я , для цели сравнения , наложил оба индикатора на один график. )

В любом случае , обе вертикали инициированы одним сигналом переворота ПКМА : в моменте завершения свечи пересечения ( обозначена на рисунке как "0" ) имеем изменение расположения линии б1 относительно линии с0 на обратное.

Почему стала возможной отрисовка второй вертикали для версии V2 данного индикатора?
Потому что кодом индикатора задана проверка : Если поступил сигнала переворота ПКМА И при этом направление пересечения линией б1 линии с0 при завершении свечи регистрации ( "3"-свечи ) имеет место быть в ту же область , куда показал сигнал переворота ПКМА И при этом завершение предыдущей свечи ( "2"-свечи ) также со-направлено с сигналом , ТО переворот подтвержден и рисуем вертикаль.

В нашем случае , действительно ( для индикатора версии V2 ) при завершении 3-й и 2-й свечей пересечение линий б1 и с0 со-направлены с направлением сигнала переворота КМА. Потому и имеем сплошную вертикаль. И она отрисована на том месте , где и должна.

Однако , суть вопроса заключается в том , что для этого сравнения нам НЕ НАДО мониторить со-направленность для свечи №2 ( А это сейчас именно так и реализовано ).
То есть расположение б1 относительно с0 в момент завершения свечи №2 ( предыдущей к свече регистрации ) НЕ участвует в сравнении.

То что на данном рисунке версия №2 индикатора правильно отрисовала сплошную вертикаль есть заслуга того , что расположение линий б1 и с0 при завершении свечи "0" , "2" и "3" со-направлены и находятся в той области , куда показывает сигнал переворота.
Но , если бы при завершении свечи "2" направление линий б1 и с0 были не со-направлены относительно сигнала переворота , то , согласно данной реализации индикатора №2 , переворот ПКМА не состоялся бы.
А нам надо , чтобы завершение свечи "2" не участвовало в этом сравнении. Смотрим только со-направленность расположения линий б1 и с0 при завершении свечи регистрации ( 3-свечи ) относительно направления сигнала переворота ПКМА.

То есть , в коде необходимо изменить логику:
Имеем сигнал на переворот ПКМА : в моменте завершения свечи пересечения ( обозначена на рисунке как "0" ) имеем изменение расположения линии б1 относительно линии с0 на обратное. И:
___________Было: подтверждается со-направленность сигнала переворота и направление пересечения линией б1 линии с0 при завершении свечи регистрации ( 3-свечи ) и при завершении предыдущей ( 2-й ) свечи.
__________Стало: Со-направленность новому сигналу перевороту и направление пересечения линией б1 линии с0 при завершении свечи регистрации ( 3-свечи ). Точка.



На рисунке ниже прерывистые вертикали - это то , что рисует версия №1. Тонкие сплошные вертикали - это то , что рисует версия №2.
Жирные сплошные вертикали - это то , что должно быть , если код индикатора №2 изменить с учетом нашего замечания. Как видно - разница огромного размера.



2.===============================
Кстати сказать , я определяю в качестве свечи пересечения - свечу , которая завершилась при новом изменении в расположении линий б1 и с0 друг относительно друга. Эта свеча обозначена как 0-свеча на рисунке.
А свечу регистрации определяю как ту , которая является 0-свеча + число задержки ( в нашем случае 0+3=3-я свеча ). И на ней мы рисуем вертикаль. Так или нет ( во всяком случае вертикаль рисуется на 3-й свече , что правильно )?

Вот на рисунке ниже свеча под номером 3 - это свеча регистрации? Или свеча регистрации - под номером 4? ( Задержка регистрации =3 , версия индикатора V2 )



3.===============================
Scriptong пишет:

цитата:

ko_ko пишет:  цитата: 3. цветность вертикалей на графике ДОЛЖНА быть сменена с точностью до-наоборот. Для этого программист не нужен, т. к. существуют настроечные параметры. Их значения легко изменить.

Давайте заглянем в код. Там есть блок "Обработка данных по пересечению средних скользящих ".
В этом блоке реализована логика: "Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх". Так вот , надо эту логику поменять на это: "Пересечение МАшкой старшего ТФ МАшки текущего ТФ снизу вверх". Результат = i_upCrossLineColor.
Аналогично для i_dnCrossLineColor , но с точностью до-наоборот.
То есть определяющей МАшкой является старшая быстрая. Результатом будет зеркальная смена цветности.
Просто ( тупо ) заменить в настройках цветность можно , но вся логика рушится , поскольку индикатор на этом этапе не заканчивается , а дальнейшая постройка индикатора должна четко придерживаться единой логики.
П.С.
Кстати сказать , во всех приводимых в качестве иллюстраций рисунках мне пришлось именно так и сделать - тупо в настройках заменить цветность.

4.===============================
4. Scriptong пишет:

цитата:

ko_ko пишет:  цитата: 4. ложные ( не подтвержденные ) перевороты КМА индикатор должен игнорировать. Это так и было. Если нашли ошибку, то приведите конкретную ситуацию, чтобы я смог воспроизвести ее у себя

Давайте объясню.
На рисунке ниже наложены 2 индикатора - версия №1 ( прерывистые вертикали ) и версия №2 ( сплошные вертикали ). Имеем 3 блока пересечений: 1-2-3 , имеющие одно направление ВНИЗ - розовые сплошные вертикали ( рисует индикатор версии №2 ).
Для индикатора 32 так быть не должно. Не может движение вниз сменяться на движение вниз и дальше сменяться на движение вниз.
Почему так произошло?
По первому пересечению вниз все ясно: и первый вариант индикатора и 2-й дают направление вниз. Там движение сильное и переплета МАшек нет.
А вот в блоках пересечений 2 и 3 мы видим множественные переплеты пересечений МАшек.
Для блока 2 индикатора №1 дает первое пересечение и оно направлено вверх. Но , поскольку с учетом задержки подтверждения не получено , то индикатор №2 не дает нам голубую сплошную вертикаль. Но после голубой прерывистой вертикали индикатор №1 дает розовую прерывистую вертикаль на следующей свече. И уже относительно нее с учетом задержки индикатор №2 подтверждает сплошной розовой вертикалью направление вниз.
На самом деле этой дублирующей вертикали не должно быть. Поскольку последовательная смена направлений предполагает действительную смену направлений. Подтверждение же предыдущего того же направления не требуется.
Мы видим , что первый сигнал вверх ( блок пересечений 2 ) в виде голубой пунктирной вертикали лишь первый сигнал. И он не был подтвержден. Но относительно этого неподтвержденного сигнала начинается поиск нового обратного к нему сигнала. Который оказывается со-направлен с прежним подтвержденным сигналом. В то время как индикатор должен остановить поиск обратного сигнала к неподтвержденному пересечению.
То есть я хочу сказать , что поиск нового обратного сигнала пересечения ПКМА должен быть только относительно подтвержденного переворота , а не ложного ( не подтвержденного сигнала ).
К сожалению , я не очень в коде разбираюсь , поэтому пришлось на словах расписать суть ошибки.
Надеюсь , рисунок ниже поможет понять то , о чем пытаюсь сказать.




П.С. 23 марта вечером внес изменение в текст.

 Отправлено: 03.04.14 14:06. Заголовок: спасибо...............

спасибо...............

 Отправлено: 04.04.14 13:56. Заголовок: ko_ko пишет: спасиб..

ko_ko пишет:

цитата:

спасибо

Пожалуйста.

По порядку, указанному в сообщении от 20.03.14
Исправление 1. Убрано подтверждение пересечения средних на баре регистрации. То есть если к моменту регистрации средние находятся уже в другом положении относительно друг друга, то пересечение все равно отображается.

Исправление 2. Пересечение регистрируется без сдвига на 1 бар. Так, если в параметре "Задержка регистрации пересечения средних, бары" указано значение 0, то вертикальные линии будут появляться на баре пересечения до момента закрытия свечи. Если к моменту закрытия свечи пересечение зарегистрировано все же не будет, то линия окажется стертой. Для точного подтверждения пересечения следует устанавливать в параметре значение больше нуля.

Исправление 3. Пересечение вверх - голубая линия выше фиолетовой. Отображается красным цветом линии. Пересечение вниз - голубая линия ниже фиолетовой. Отображается синим цветом линии.

Исправление 4. С изменением п. 1 очередность будет точная.


Четвертая версия

 Отправлено: 05.04.14 00:25. Заголовок: Scriptong пишет: Ис..

Насколько я понял последняя версия №4 рисует линии точно так же , как 1-я версия - на свече пересечения. А наличие параметра задержки подтверждения в 4-й версии никак не влияет на отрисовку... Давайте разберемся почему так ( к сожалению ) получилось.....
( П.С. - для каждого пункта базовая мысль сконцентрирована в выделенном крупным , зеленым , жирным шрифтом тексте. Достаточно его прочитать и понять посыл. )
1.
Scriptong пишет:

цитата:

Исправление 1. Убрано подтверждение пересечения средних на баре регистрации. То есть если к моменту регистрации средние находятся уже в другом положении относительно друг друга, то пересечение все равно отображается.

В таком случае мы вернулись к тому , что реализовано версией №1. Когда не было задержки регистрации и вертикаль рисовалась при первом же сигнале на свече пересечения.
Суть же того , что было озвучено прошлым постом заключается в том , что ДА , мы не сравниваем расположение средних для свечи регистрации и СОСЕДНЕЙ свечи. НО!!!
мы должны сравнить расположение средних для свечи регистрации и свечи пересечения в моментах их завершения.
Если они идентичны ( со-направлены ) в момент завершения , то пересечение регистрируется. Если не со-направлены , то пересечение не подтверждено и не рисуется. В этом контексте надо доработать код , добавив оператор: "И" + "со-направленность в расположении средних при завершении свечи пересечения и свечи регистрации в моменте ее завершения".

Сейчас же получилось , что при первом же пересечении средних ( на свече пересечения ) индикатор регистрирует это пересечение не взирая на то со-направлены ли или нет направления пересечения средних для свечи пересечения и свечи регистрации.
Что и приводит к тому , что первый сигнал пересечения средних ( на свече пересечения ) дает истинность пересечения ВНЕ ЗАВИСИМОСТИ от того , какое направление пересечения на свече регистрации. Со-направлено или нет. И хоть задержка 0 , хоть 10 , хоть 33 - все равно вертикаль рисуется - индикатору сугубо фиолетово на направленность средних для свечи пересечения и любой другой последующих свечей. Главное , что на свече пересечения есть смена направления - а там хоть трава не расти.

Нам же надо , чтобы направление пересечения средних для свечи пересечения и свечи регистрации СОВПАДАЛИ в моментах завершения этих свечей. Только тогда рисуем вертикаль.
И , если задержка=3 , то , в случае , если свеча регистрации определяется как 0+3=3 , тогда рисуем вертикаль на этой свече регистрации - рисунок №3 прошлого поста. Это вертикаль для свечи №3.
Если же свеча регистрации определена , как 0+3=4 ( то есть 4-я свеча ) , то рисуем вертикаль на свече , предшествующей свечи регистрации , то есть тоже на 3-й свече - рис. №3 прошлого поста.
( П.С. = просто я так и не понял какая из свечей является в индикаторе свечей регистрации - 3-я или 4-я , если рассматривать рис. №3 прошлого поста )
======================
2.
Scriptong пишет:

цитата:

Исправление 2. Пересечение регистрируется без сдвига на 1 бар. Так, если в параметре "Задержка регистрации пересечения средних, бары" указано значение 0, то вертикальные линии будут появляться на баре пересечения до момента закрытия свечи. Если к моменту закрытия свечи пересечение зарегистрировано все же не будет, то линия окажется стертой. Для точного подтверждения пересечения следует устанавливать в параметре значение больше нуля.

Нет - немного не так.
Если задержка =0 , то вертикальная линия должна рисоваться после завершения свечи пересечения и на свече пересечения. Без всяких перерисовок и стираний.

Если свеча регистрации определяется как "0+3=3 свеча" , то:
при задержке=0 , свеча регистрации совпадает со свечей пересечения ( рис. №3 прошлого поста - свеча "0" ). Но сама вертикаль рисуется только по результату завершения свечи пересечения. На свече регистрации , совпадающей в данном случае со свечей пересечения.
Если задана задержка =3 , то свеча регистрации - это 3-я свеча ( рис. №3 прошлого поста ) и на ней рисуем вертикаль при со-направленности средних для этой свечи регистрации и свечи пересечения по завершении свечей.

Если же свеча регистрации определяется как "0+3=4 свеча" ( рис. №3 прошлого поста ) , то:
при задержке=0 , свеча регистрации - это первая после свечи пересечения свеча , но вертикаль рисуем на предшествующей свече , которая совпадает со свечей пересечения.
Если задана задержка=3 , то имеем свечу регистрации - это 4-я свеча ( рис. №3 прошлого поста ). Тогда вертикаль отображается на 3-й свече ( то есть предшествующей свечи регистрации ).

То есть в зависимости от того , какая свеча принимается в качестве свечи регистрации , мы рисуем вертикаль либо на самой свече регистрации , либо на предшествующей ей свече. Это я имел ввиду , когда говорил о сдвиге вертикали. Просто , повторюсь , я не знаю где в коде смотреть какая свеча назначается свечей регистрации. А ответ на вопрос п.2 прошлого поста вы не дали. Потому приходится писать вариантно.

В любом случае , при задержке=3 , вертикаль должна быть на свече №3 ( рис №3 прошлого поста ). И никаких перерисовок и стираний вертикалей.
Состояние пересечения средних определяется по закрытию свечи. Как свеча закрылась , так и появилась вертикаль , если произошел переворот КМА.
И , если задана задержка=0 , то вертикаль рисуется после завершения свечи пересечения на свече пересечения. При задержке=3 , вертикаль рисуется тоже после завершения свечи регистрации на свече регистрации ( если принцип определения свечи регистрации "0+3=3" ) или на предшествующей свече ( если принцип определения свечи регистрации определен как "0+3=4 свечи" ).
Но , в любом случае , вертикаль рисуется только после завершения свечи регистрации. А , значит , не перерисовывается и не стирается.
===================================
3.
Scriptong пишет:

цитата:

Исправление 3. Пересечение вверх - голубая линия выше фиолетовой. Отображается красным цветом линии. Пересечение вниз - голубая линия ниже фиолетовой. Отображается синим цветом линии.

Уххххххххх.............. пробую объяснить через код.
Вот строки кода №№ 306-311:
Скрытый текст

string name = PREFIX + DoubleToStr(Time[curBar], 0); // Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх if (g_ma2CurTF[curBar] > g_ma1HigherTF[curBar] && g_ma2CurTF[curBar + 1] < g_ma1HigherTF[curBar + 1]) { ShowVLine(PREFIX + DoubleToStr(Time[curBar], 0), 0, Time[curBar], i_upCrossLineColor); return;

Согласно логики данного кода главная линия - это текущая , средняя МА ( голубого цвета ). Ее выход снизу вверх определяет направление пересечения. И это направление - ВВЕРХ. Что мы и видим в коде: i_upCrossLineColor .
Но почему-то предлагается тенить вертикаль красным цветом , а не синим. Ведь общепринятый формат : движение вверх - синий цвет , движение вниз - красный формат.
Вот эта путаница общепринятого ( логичного ) и приведенного под ситуацию ( i_upCrossLineColor = красного цвета ( вниз )) дает жесткую аберрацию сознания ( смена полюсов ).
Ведь логика подсказывает , что i_upCrossLineColor = это UP = вверх , голубой цвет. И обратно: i_dnCrossLineColor = Dn = вниз , красный цвет.

Положим , я , как автор , знаю , что в настройках параметр "Цвет линии пересечения средних ВВЕРХ" должен обозначить красным. Об этом также знает исполнитель. И то , через месяц-другой забудется , поскольку это аллогично.
Любой другой пользователь , прочитав слово "вверх" , настроит цвет синим. Это логично.
Но совсем нелогично это будет выглядеть на графике , когда у него красным будет показывать движение вверх , а синим движение вниз. Но так это выглядит сейчас. И так мы видим это в коде.

логика требуемая.
Я в прошлом ( да и раньше ) посте писал , что логика индикатора - быстрая старшего ( как главная линия ) пересекает среднюю текущего ( как подчиненная ) линию ( сиреневая пересекает голубую ) . И , в зависимости от направления этого пересечения , определяется направление ПКМА.
Если быстрая старшего ( фиолетовая ) пересекает среднюю текущего ( голубая ) снизу вверх , то имеем направление ПКМА_UP. И вертикаль СИНЯЯ.

логика текущая.
Сейчас же принцип главной линии , определяющей направление ПКМА , не изменен. Во всех версиях главная линия - средняя текущего ТФ ( голубая ). И пересечение ею быстрой старшего ТФ ( сиреневой ) дает направление UP и обозначается КРАСНОЙ вертикалью.

Согласитесь , это 2 разные логики.

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

Давайте подход сделаем таким.

Пусть , как сейчас , главная - это средняя текущего ( голубая ). Но в коде отметим , что "Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх" дает i_dnCrossLineColor = Dn = вниз , красный цвет ( сейчас это UP и красный цвет ).

И тогда в коде ( блок "Обработка данных по пересечению средних скользящих" ( строка 297 кода )) :
первая часть блока будет звучать так:
"// Пересечение МАшкой текущего ТФ МАшки старшего ТФ сверху вниз" и i_upCrossLineColor = синий.
Что означает , что первая часть блока описывает направление "ВВЕРХ"
вторая часть блока будет звучать так:
"// Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх" и i_dnCrossLineColor = красный.
Что означает , что вторая часть блока описывает направление "ВНИЗ".

А на выходе ( на графике ) синяя вертикаль будет показывать направление вверх , а красная - направление вниз. Что логично и общепринято.
Даже при том , что вынуждено за главную линию МА принимаем среднюю текущего ТФ ( голубая ). Но в новой редакции пересечение ею сиреневой линии ( быстрая старшего ТФ ) вниз будет восприниматься , как общее направление ВВЕРХ ( а не ВНИЗ - как сейчас ) с отрисовкой синей вертикали.
В этом случае ( вынужденное принятие за главную линию текущую среднюю ( голубая )) при описании в последующих ТЗ я буду этот момент учитывать.
====================
4.
В силу выше-написанного просьба также обратить внимание на п.4 прошлого поста. Поскольку изменение п.1 в редакции версии №4 индикатора вернул индикатор к версии №1 , где задержки подтверждения переворота не было.
Но , если все-таки реализовать индикатор так , как это описано в п.1 прошлого поста или п.1-2 этого поста , то глюк , о котором я писал в прошлом посте , возникнет. Как его решить , я описал в прошлом посте , потому повторять не стану.

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

 Отправлено: 11.04.14 20:34. Заголовок: 1. К сожалению, Вы п..

1. К сожалению, Вы противоречите самому себе. Ранее Вы писали:

цитата:

Однако , суть вопроса заключается в том , что для этого сравнения нам НЕ НАДО мониторить со-направленность для свечи №2 ( А это сейчас именно так и реализовано ). То есть расположение б1 относительно с0 в момент завершения свечи №2 ( предыдущей к свече регистрации ) НЕ участвует в сравнении.

Сейчас же снова пишете, что нужна проверка:

цитата:

мы должны сравнить расположение средних для свечи регистрации и свечи пересечения в моментах их завершения. Если они идентичны ( со-направлены ) в момент завершения , то пересечение регистрируется. Если не со-направлены , то пересечение не подтверждено и не рисуется

Разберитесь уже с этим вопросом.

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

3. Снова очень много слов, но нет главного: как нужно то? Напишите четко: пересечение вверх - это..., пересечение вниз - это... Сколько раз уже просил не рассекать мысью по древу.

4. В текущей версии индикатора очередность четкая, т. к. пересечение вниз не может вновь возникнуть, пока не появится пересечение вверх. А вот как только будет введено подтверждение, то четкой очередности не будет. Над этим еще работа не велась. Да и как ей вестись, если подтверждение то нужно, то не нужно?

 Отправлено: 19.04.14 23:21. Заголовок: Вот 3-й рисунок пост..

1. Вот 3-й рисунок поста от 20.03.14 18:34.

0-свеча = свеча пересечения. Задано: Задержка регистрации=3. Принимаем вариант , когда свеча регистрации определяется как "0+3=4 свеча" , тогда 4-я свеча = свеча регистрации.
Предшествующей свечей относительно свечи регистрации является 3-я свеча. На ней и ставим вертикаль.


Сравниваем со-направленность пересечения линий МА ( б1 и с0 ) по моменту завершения 0-свечи ( свеча пересечения ) и 4-свечи ( свеча регистрации ).
Если со-направленность присутствует , то переворот КМА состоялся и вертикаль рисуем на 3-й свече.
Если ложь , то переворот не состоялся и мониторим далее , начиная от следующей свечи после 0-свечи ( при которой переворот машек не подтвердился ).

Scriptong пишет:

цитата:

Разберитесь уже с этим вопросом.

Эти 2 абзаца не противоречат друг другу.

Согласно 2-го абзаца , со-направленность переворота КМА сравнивается для свечи ПЕРЕСЕЧЕНИЯ ( 0-свеча на рисунке ) и свечи РЕГИСТРАЦИИ ( 4-свеча на рисунке ) по моменту их завершения.

В текущем же индикаторе , после того , как 0-свеча ( свеча пересечения ) зафиксировала переворот КМА , сравниваются свеча РЕГИСТРАЦИИ и ПРЕДШЕСТВУЮЩАЯ к ней свеча , то есть сравниваются завершение 4-свечи и 3-свечи.

Согласитесь , имеем 2 разных подхода.

При этом имеется ввиду , что :
1. Моментом нового направления является пересечение МА-линий б1 и с0 в обратном от текущего направлении. И в момент завершения 0-свечи ( свечи ПЕРЕСЕЧЕНИЯ ).
2. Со-направленность к этому , новому , направлению - это аналогичная направленность МАшек ( б1 и с0 ) для сравниваемой свечи тоже в момент завершения. В нашем случае , при заданной задержке=3 , - это 4-свеча ( свеча РЕГИСТРАЦИИ ).
Если есть со-направленность , то вертикаль пересечения ставим на свече , предшествующей свече регистрации , то есть на 3-й свече.
Так должно быть.

П.С.
Немного может смутить , что в первом абзаце , на которое Вы ссылаетесь в прошлом посте , было указано "свеча №2"....
Но это было указано для другого рисунка , в котором свечей регистрации была свеча №3 , а ей предшествующая была №2. И , если отойти от обозначения номера свечи , а "свеча №2" читать как ПРЕДШЕСТВУЮЩАЯ свечи РЕГИСТРАЦИИ , то суть первого абзаца выстраивается также и в отношении к вышеприведенному рисунку.
И при этом видно , что суть первого и второго из приведенных Вами абзацев будут не-противоречить друг другу.
Кроме этого , ПРЕДШЕСТВУЮЩАЯ свеча не участвует в сравнении , а лишь на ней фиксируется вертикаль , но только если со-направленность подтверждена.

2.
Здесь , я уже писал в прошлом посте почему идет разночтение:
ko_ko пишет:

цитата:

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

В 3-й версии вертикаль ВООБЩЕ рисовалась непосредственно на свече ПЕРЕСЕЧЕНИЯ. А надо на свече регистрации ( если свеча регистрации определяется как "0+3=3 свеча") или на свече , предшествующей свечи регистрации ( если свеча регистрации определяется как "0+3=4 свеча" ).
Во 2-й версии , действительно , вертикаль рисовалась на свече , отличной от свечи пересечения. Но там ясно видно , что в определении со-направленности участвовала предшествующая свеча при подтверждении. Но она не должна участвовать.
По 4-й версии я не могу ничего сказать , поскольку там вертикаль вообще тупо рисуется , как в версии_0 , то есть на 0-свече ( свеча пересечения ) и без всяких подтверждений ( хотя настройками задается , но не влияет на отображение - во всяком случае так видится на графике ).

У меня складывается впечатление , что Вы иногда путаете названия свеч ( ПЕРЕСЕЧЕНИЯ , РЕГИСТРАЦИИ , ПРЕДШЕСТВУЮЩАЯ ). Давайте , что ли , уточню названия.
1. Свеча ПЕРЕСЕЧЕНИЯ ( или 0-свеча ) - это свеча , которая на рисунке выше обозначена как "0".
2. Свеча РЕГИСТРАЦИИ. Если задержка=3 , то ( в зависимости от принятого правила для свечи регистрации ):
.........если принять правило: "свеча регистрации определяется как "0+3=4 свеча" , то свеча регистрации - это 4-я свеча ( на рисунке ). В этом случае ПРЕДШЕСТВУЮЩАЯ к свече регистрации - 3-я свеча ( на рисунке ). На ней ставим вертикаль.
.........если принять правило: "свеча регистрации определяется как "0+3=3 свеча" , то свеча регистрации - это 3-я свеча ( на рисунке ). В этом случае ПРЕДШЕСТВУЮЩЕЙ свечи к свече регистрации нет. То есть вертикаль рисуется на свече регистрации - на 3-й свече ( на рисунке ).
В любом из этих двух вариантов ПРЕДШЕСТВУЮЩАЯ свеча ( к свече регистрации ) не участвует в сравнении для цели со-направленности. А только лишь относится к тому будет к ней привязана вертикаль или нет.

3.
Scriptong пишет:

цитата:

как нужно то?

Чтобы не переделывать сильно код , просто последние строки из прошлого поста , раздел 3 ( выдержка ):
Скрытый текст

Если по каким-либо причинам нет возможности назначит быструю старшего ТФ главной линией , то давайте в коде изменим подход. И этот момент я буду в дальнейшем учитывать в следующих ТЗ. Давайте подход сделаем таким. Пусть , как сейчас , главная - это средняя текущего ( голубая ). Но в коде отметим , что "Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх" дает i_dnCrossLineColor = Dn = вниз , красный цвет ( сейчас это UP и красный цвет ). И тогда в коде ( блок "Обработка данных по пересечению средних скользящих" ( строка 297 кода )) : первая часть блока будет звучать так: "// Пересечение МАшкой текущего ТФ МАшки старшего ТФ сверху вниз" и i_upCrossLineColor = синий. Что означает , что первая часть блока описывает направление "ВВЕРХ" вторая часть блока будет звучать так: "// Пересечение МАшкой текущего ТФ МАшки старшего ТФ снизу вверх" и i_dnCrossLineColor = красный. Что означает , что вторая часть блока описывает направление "ВНИЗ".

4.
По п4 с Вами соглашусь. Но , поскольку , настаиваю , что подтверждение необходимо , то и решать этот вопрос надо.
А как решать написано в п.4 от 20.03.14 18:34.

 Отправлено: 25.04.14 14:12. Заголовок: Извините, но дальней..

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

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

Для ведения подобных проектов пробуйте заинтересовывать разработчиков в плане самой идеи.

 Отправлено: 16.06.15 12:14. Заголовок: Если, исходить из то..

Если, исходить из того, что тренд считается восходящим, когда CCI пересёк уровень +100 снизу вверх и до тех пор, пока не пересёк -100 сверху вниз,
то противоположные показания MAChannel_Close_AD можно считать флетом.



C настройками, как здесь, на М30 получается лучше, "виднее".