[b]Разработчикам:[/b] и снова о желаемой привязке объектов к бару...

Новый комментарий
 
Господа разработчики!

Цитирую себя (контекст см. в ветке "Построение линий в будующее"):

...Следовательно, должна существовать возможность ставить объекты именно по барам, не привязывая их к определенному астрономическому времени.


Либо - еще один вариант: устранить запрет на отрицательные значения параметра shift в функции iTime, чтобы можно было как-то вычислять время будущих баров (пусть даже без календаря, который можно реализовать и программно).


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

1. Почему в индикаторах есть встроенная прямая привязка к бару, даже к будущему, а у Arrow такую возможность так трудно реализовать?

2. Почему по функции iTime() нельзя получить время некоторого будущего бара - пусть даже по линейной модели будущего времени, без выходных?

3. Существует ли хоть какой-нибудь кривой способ в данном билде МТ4 для привязки Arrow к конкретному бару в будущем или нет?

Моя первоначальная задача, в связи с которой я пытаюсь решить эту проблему, заключалась в том, чтобы воткнуть Arrow в каждый узел сетки, образованной пересечением Fibo ret и Fibo Time Zones от одного свинга.

С помощью индикатора задача решается, но неточно и крайне неудовлетворительно: для обработки одного-единственного свинга и построения чуть более 100 элементов требуется несколько отображаемых буферов. Картинка весьма кривой реализации на примере двух свингов прилагается. Могу добавить, что там мне потребовалось 6 буферов, причем каждый - для отображения всего-то 18 точек.

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



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

Кстати, проблема Kostikus, "Построение линий в будующее", связана именно с привязкой опорных точек трендов ко времени, а не так, как правильно, - к бару...

Вот и хочется реализовать то же самое, что на рисунке, - но не индикатором, а просто скриптом, так как объекты Arrow никуда смещаться относительно уровней Fibo Time Zones не будут, и пересчитывать их с каждым новым тиком совсем не нужно.

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

С уважением и НП.

P.S. Еще дополнение: Arrow я ставлю только в будущем, потому что именно оно меня и интересует.
 
Ваша аргументация понятна. к сожалению, в текущей версии клиентского терминала мы не сможем сделать привязку к бару. (я правильно понял? дать возможность задавать временнЫе координаты в виде время + смещение в барах?)
так получилось, что в предыдущей версии MT не было возможности рисовать в будущем. поэтому никто не сделал нам такого предложения на этапе проектирования системы. было простое пожелание - рисовать объекты в будущем, без таких подробностей.
 
Спасибо, Slawa, за ясный ответ. Ну ничего, выкрутимся, не впервой.

(я правильно понял? дать возможность задавать временнЫе координаты в виде время + смещение в барах?)


Ну можно и так. Или, например, так: исходный бар + смещение в барах. Так даже прямее, хотя принципиальной разницы нет, так как в прошлом бары и время связаны взаимно однозначно (если прошлая история не меняется).

С уважением и НП.
 
Ваша аргументация понятна. к сожалению, в текущей версии клиентского терминала мы не сможем сделать привязку к бару. (я правильно понял? дать возможность задавать временнЫе координаты в виде время + смещение в барах?)
так получилось, что в предыдущей версии MT не было возможности рисовать в будущем. поэтому никто не сделал нам такого предложения на этапе проектирования системы. было простое пожелание - рисовать объекты в будущем, без таких подробностей.


Хороший ход Slawa :) Но в виду того, что по результатам пользовательского тестирования, предложенное вами решение признано непригодным для пользования конечным пользователем, прошу вас подумать над новым решением. Думаю вам очень помогут результаты анализа проблемы господина Mathemat'а. Я считаю что его предложение реализации оптимально с точки зрения трудозатрат. А так же отсутствeт риск повторного попадания в просак, т.к. господин Mathemat является в том числе и конечным ползователем продукта, и его поддерживают другие пользователи.
:)
 
эта проблема поднималась несколько раз. я даже открыто заявил, что не понимаю её важности, так как объяснения со стороны пользователей были действительно мне не понятны. наконец, Mathemat сумел внятно и вполне аргументированно её объяснить. у него не сразу это получилось, но получилось. надо думать. здесь много нюансов. например, линия построенная на часовке указанным способом (время бара + смещение) может быть применима только к этой самой часовке. при переключении на другой таймфрейм это построение теряет смысл.
 
здесь много нюансов. например, линия построенная на часовке указанным способом (время бара + смещение) может быть применима только к этой самой часовке. при переключении на другой таймфрейм это построение теряет смысл.


Согласен. Если Вы имеете в виду то, что 15 баров на часовках совсем не обязательно должны превратиться в 15*60 баров на минутках. Будет значительно меньше - и 750 может получиться. Эту цифру программа, конечно, не просчитает для будущего. А кто сказал, что это должна делать программа, а не юзер? Пусть ответственность будет на нем. В своем индикаторе я сам считаю бары, и, так как это индикатор, то при переключении ТФ пересчет по моему алгоритму происходит автоматически.

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