Спасибо..

Полностью поддерживаю.


возможно "все" не догадываются о том, что это им тоже может пригодиться. )



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

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

("Главное,чтобы у полученных графиков (индикаторов) были соответствующие характеристики: open. close. min. max.(int)")

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

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

Например запрашиваемые графики сделать в виде отдельных индикаторов, как например сделали с хейко аши.

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

PS. Я вообще согласен, что было бы неплохо расширить программу, но пока не понимаю как это сделать в общем случае. Пока здесь расписаны только частные.

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

Программистом быть не нужно, достаточно подробно описать подобное решение В волфиксе они показывают несколько бумаг на одном графике?

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

Про волфикс не знаю как там реализуется, но задача не сложная: За торговый день на мамбе проходит 9, с небольшим часов, мы (вы) их нарезаем на ломтики по 1/5/15 мин. каждый, или как угодно. в этих дискретных ломтаких мы отмечаем минимум цены, максимум цены, открытие и закрытие. так вот с объёмом то же самое: за торговый день проходит 100 мильёнов сделок (или сколько там проходит в среднем? это и не имеет значение) сделок, мы называем это объёмом. Дальше нарезаем эти объёмы на мелкие дискретные кусочки, ну скажем по 1000 или по 10000, неважно, важно, что это должно быть регулируемое значение. И вот на каждом таком ломтике (пока копится определённый, заданный объём) мы и отмечаем минимум цены, её максимум, открытие и закрытие. Таким образом получаем те же свечи или бары, но привязанные не ко времени, а к объёму.
Теперь о двух бумагах в одном окне: да не надо двух в одном окне, пусть будут в разных или поставить запрет на второй график, как написано выше.
С ренко принцип похожий (правда не знаю нужно кому то ренко, но видимо кто то захочет и его юзать). Пока цена не вышла за заданный диапазон за определённое время (ну скажем за минуту/три/5/15 и т.д, новая свеча не рисуется. Т.е. клоз минус опен не перешёл задаваемую границу, свечу не рисуем.
для чего? отсеить флэт, скальперов, игры кукла с пробиванием стакана. будут ли лучше стратегии, скрипты показатели нашей торговли? не знаю. пока не попробую не скажу насколько это актуально? да хорошо бы надо шевелить поршнями в ногу со временем (и объёмами)))
надеюсь достаточно подробно описал...

captian это я уже описывал в соответствующей ветке заказ индикаторов ещё летом кажется 2010.разработчики решили что не надо пока,хотя всем бы хотелось юзать скрипты в такой частоте новой,вдруг стрельнет?

Насчет отображения "в одно окно" проблема не понятна.

На одной панели уважаемые разработчики сумели отобразить графики с разным
масштабом по оси Y.
В программе есть замечательная кнопка "Добавить новую шкалу" (для оси Y)
И графики, которые привязаны к этой шкале отображаются в своем масштабе.
С этим ведь всем все понятно.

Чем ось X отличается от оси Y?
Ничем, кроме того, что ее (ось X) привыкли рисовать горизонтально )
Ведь никто не мешает повернуть оси X и Y на 90градусов против часовой стрелки
и рисовать график вверх.

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

Т.е. сейчас лубой график как сущность "знает" про шкалу для оси Y
и точно также он (график - источник данных) должен будет "знать" про шкалу для оси X.
Т.е. "Панель" как сущность (ось X) должна быть превращена в массив шкал для оси X, а "Панель"[0] (первая шкала оси X) в частном случае, будет соответствовать шкале времени.

Все тоже самое "только вид сбоку"
и не надо надуманных ограничений )

captian всё разжевал, этот функционал нужен, есть же кластерный анализ, сделать лбязательно необходимо!!!!

Про скрипт и выравнивание бумаг тоже не понятна проблема.
Насколько я понял про скрипт - речь о том как в скрипт передавать несколько источников, которые могут относится к разным шкалам?

В общем случае графики, привязанные к разным шкалам оси X, могут иметь различную длину (количество отсчетов).
И отношение отсчетов графиков с разными шкалами оси X будет многие ко многим.
т.е. одному бару по шкале времени в момент времени t (X0[t])может соответсвовать несколько (n) баров другой шкалы (X1[i],..,X1[i+n]),
также как одному бару шкалы X1 (X1[j]) может соответсвовать несколько (m) баров другой шкалы X0 (X0[t],..,X0[t+m])


"Если бумаг несколько" и они привязаны к разным шкалам оси X,
то они об этом должны "знать" и тогда они могут быть "выровнены" по своей шкале.

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

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

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

График с произвольной шкалой X в любом случае будет производным от минутного или тикового графика. т.е. будет формироваться каким-то алгоритмом - внешним скриптом или реализованным разработчиками TSLab кубиком.

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

Доступ к соответствующим значениям графиков с другой шкалой оси Х вполне реализуем.
Например можно получить индекс соотвесвующего бара с другой шкалой X
методом "Last(t)" т.е. получить номер последнего бара на момент времени <= t.
т.е. использование формул вполне допустимо даже для данных с разными шкалами Х.
Визуальный редактор и скрипт им формируемый должны будут "знать" какая шкала будет "основной" или "ведущей" в алгоритме.

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