Графическое перекрестие трендовых линий, функция ObjectGetValueByTime что с ней не так? - страница 2

 
Nikolai Semko:

эта задача решена в классе iCanvas. Изучайте на здоровье. 
Просто нужно переходить от типа int к типу double. 

Уйдите от объектов и придите к Канвас через мой класс iCanvas. И будет Вам счастье, код гораздо короче, а возможностей гораздо больше и скорость гораздо выше.

Я видел вашу библиотеку, но не все ее будут использовать. 

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

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

 
Martingeil:

Я видел вашу библиотеку, но не все ее будут использовать. 

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

я дал Вам ответ. Все int координаты необходимо перевести в double и работать только с double. Ведь, например, если линия-объект на дневном ТФ у вас начинается в среду, то на недельном ТФ она будет начинаться в понедельник из-за округления до int значения бара. Отсюда и все рассогласования. Но если у вас линия будет начинаться, например с 152.2857142 недельного бара (а не с 152), тогда ошибок не будет. С объектами Вы это сделать не сможете, а с iCanvas сможете. Там все координаты в типе double и даже есть функция :

LineD(double x1,double y1,double x2,double y2,const uint clr);
 
Nikolai Semko:

я дал Вам ответ. Все int координаты необходимо перевести в double и работать только с double. Ведь, например, если линия-объект на дневном ТФ у вас начинается в среду, то на недельном ТФ она будет начинаться в понедельник из-за округления до int значения бара. Отсюда и все рассогласования. Но если у вас линия будет начинаться, например с 152.2857142 недельного бара, тогда ошибок не будет. С объектами Вы это сделать не сможете, а с iCanvas сможете. Там все координаты в типе double и даже есть функция :

Это значит что даже если передавать в функцию время дневного тф для двух линий, что я и делаю в принципе

// Цена перекрестия
     pricy2 = PriceY(R1, R2, Rw2_1,Rw2_2, t1,t2,t1,t2);

где t1 - время первой координаты линии №1  х1,   t2 - время второй координаты линии №1    х2,  t3 - время первой координаты линии  №2  х3,   t2 - время второй координаты линии  №2    х4 

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

цена полученная, получается искажает время по вашему в функции ObjectGetValueByTime

Rw2_1  = ObjectGetValueByTime(0,"Rw2["+i+"]"+z,timed1,0);      Rw2_2  = ObjectGetValueByTime(0,"Rw2["+i+"]"+z,timed2,0);
 

Индикатор с линиями прекрасно работает. Время корректно выставляется. Но с перекрестиями нужно добавлять условия.

1 2 3

 
Martingeil:

Это значит что даже если передавать в функцию время дневного тф для двух линий, что я и делаю в принципе

где t1 - время первой координаты х1,   t2 - время второй координаты х2,  t3 - время первой координаты х3,   t2 - время второй координаты х4 

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

цена полученная получается по вашему искажается в функции ObjectGetValueByTime

я не буду тратить время на вникание в Ваш код. Вы же не хотите вникать в мой код. )) Просто если есть факт рассогласования, значит есть неправильная логика. Я видел ваши double, но я не знаю, что Вы дальше с ними делаете. У меня были такие же проблемы и я очень долго промучался с этим (уже 30 -ая версия iCanvas, т.к. выявлялись все новые моменты с координатами типа double). Здесь еще есть некоторые факторы.
Например, если две линии построены на минутных барах, и мы их переносим на дневные бары, то нужно понимать, что каждый дневной бар содержит разное количество минутных баров, особенно суббота и воскресенье (у некоторых брокеров эти бары существуют) и если добиваться полной идентичности, чтобы точки пересечения совпадали, то эти линиии на дневных барах не будут прямолинейными, а кривыми.
Так же не в каждом 5 -ти минутном баре 5 минутных баров и т.д.  

 
Nikolai Semko:

я не буду тратить время на вникание в Ваш код. Просто если есть факт рассогласования, значит есть неправильная логика. Я видел ваши double, но я не знаю, что Вы дальше с ними делаете. У меня были такие же проблемы и я очень долго промучался с этим. Здесь еще есть некоторые факторы.
Например, если две линии построены на минутных барах, и мы их переносим на дневные бары, то нужно понимать, что каждый дневной бар содержит разное количество минутных баров, особенно суббота и воскресенье (у некоторых брокеров эти бары существуют) и если добиваться полной идентичности, чтобы точки пересечения совпадали, то эти линиии на дневных барах не будут прямолинейными, а кривыми.
Так же не в каждом 5 -ти минутном баре не 5 минутных баров и т.д.  

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

 
Martingeil:

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

Каждый ТФ вносит свое искажение в поток времени. Искажений бы не было, если бы в каждом часе было бы 60 минутных баров, в неделе 7 дневных баров, в каждом дне 24 часовых баров и т.д. вне зависимости есть торговля или нет, выходной или торговый день. Другими словами каждый недельный бар должен содержать ровно 7*24*60 = 10080 минутных баров. Опять же в канвасе это легко сделать(дорисовывать недостающие бары). Так же другим решением является использование ренко баров. Но там плотность времени уже непостоянная величина, но зато плотность изменения цены становится величиной постоянной.
А применение типа double в координатах полностью не решает эту проблему, но значительно улучшает точность и предоставляет возможность к маневру.

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

 
Nikolai Semko:

Каждый ТФ вносит свое искажение в поток времени. Искажений бы не было, если бы в каждом часе было бы 60 минутных баров, в неделе 7 дневных баров, в каждом дне 24 часовых баров и т.д. вне зависимости есть торговля или нет, выходной или торговый день. Другими словами каждый недельный бар должен содержать ровно 7*24*60 = 10080 минутных баров. Опять же в канвасе это легко сделать(дорисовывать недостающие бары). Так же другим решением является использование ренко баров. Но там плотность времени уже непостоянная величина, но зато плотность изменения цены становится величиной постоянной.
А применение типа double в координатах полностью не решает эту проблему, но значительно улучшает точность и предоставляет возможность к маневру.

время1 == открытие дневной предыдущей свечи, --- оно одинаковое для обоих линий

время2 == открытие дневной свечи,                      --- оно одинаковое для обоих линий

и не важно сколько баров внутри любого тф, оно будет на любом графике одинаковое в этом промежутке времени.

 
Martingeil:

время1 == открытие дневной предыдущей свечи, --- оно одинаковое для обоих линий

время2 == открытие дневной свечи,                      --- оно одинаковое для обоих линий

и не важно сколько баров внутри любого тф, оно будет на любом графике одинаковое в этом промежутке времени.

Время в этом промежутке будет одинаковым, но количество минутных баров будет разным. 
Ведь количество минут между соседними недельными барами будет 10080. А на минутном графике реальных минутных баров между соседними понедельниками 00:00 будет гораздо меньше, и так по всем ТФ.

 
 Мне думается, что абсолютным решением данной задачи будет введение такого понятия, как толщина бара в минутных барах. При этом количество баров останется оригинальным, но графики будут немного выглядеть по другому, так так некоторые бары таймфреймов старше М1 будут более "худыми". Графики на всех ТФ будут выглядеть точно также как уменьшенная копия минутного ТФ. Сейчас же в MT чем старше ТФ, тем график более искажен, более "растянут", если наложить на него копию минитного графика уменьшенного масштаба. 
Но для этого нужет абсолютно новый интерфейс, который можно реализовать опять же на Canvas.
Причина обращения: