Multiframe MA

Ничего нового, просто любую MA транслировать на более мелкий таймфрейм. То есть если в моменте значение дневного EMA равно 120, то внутри дня значение 120 будет одинаковое на всех часовых свечках и будет в реальном времени уточняться. В конце дня оно зафиксируется, то же самое в следующий день. В итоге тот же дневной ЕМА будет на дневном таймфрейме плавный, как обычно, а на часовом будет в виде лесенки, как на скриншоте (с длиной ступенек равной 10 часовых свечей внутри дня).
PS Желание есть, попробую разобраться с lua :)

А что мешает на более мелком таймфрейте просто удлинить период МА в N раз?
Тупо. Руками. А?

Здравствуйте!

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

Эти расхождения несущественны.

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

Roman Koledin, добрый день
Компания с большим вниманием относится к пожеланиям пользователей,  стараясь реагировать на них максимально оперативно, понимая  востребованность тех или иных доработок.

В тоже время возможности  сделать "всё и сразу" мы не имеем, т.к. штат разработчиков помимо  видимого конечным клиентам функционала работает и над массой других  проектов: в их состав, помимо Рабочего места QUIK, входит сервер, на  котором обсчитывается вся бизнес-логика, более 20 функциональных  модулей, несколько видов специализированных терминалов, утилиты для  решения служебных задач. Штат разработчиков занят развитием всех  элементов системы, т.к. изменение в одном неизбежно влечет за собой  корректировку функционала остальных компонентов и необходимость их  тестирования. С этим связаны продолжительные сроки выхода новых версий  программы.

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

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

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

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

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