Форум » Статьи MQLabs » Что скрывают свечи? » Ответить
Что скрывают свечи?
Scriptong: Часть 1 Вычисление сил быков и медведей на основании тиковой истории, взятой в пределах одной свечи текущего таймфрейма - индикатор BearBullBalanceOnticks. Также на основании тиковой истории определяются уровни максимального объема, действующие в пределах одной свечи - индикатор AnyTFVerticalHistogramm. Часть 2. Модернизация сборщика тиков для обновленного MQL4. Изменение условий регистрации уровней максимальных объемов. Часть 3. Приближение вида графика к кластерному виду. Обновление от 17.09.14 для первых трех частей Улучшенная версия сборщика тиков. Новые версии подсчета сил быков и медведей. Важные уровни внутри свечи, они же приближение вида графика к кластерному виду - Вертикальное сечение рынка. Часть 4. 1. В сборщик тиков добавлен принудительный сброс накопленных данных с частотой, выраженной в тиках, что регулируется трейдером. 2. Разработана версия ClusterBox (ClusterBox_Histogramm), отображающая данные в виде гистограммы интерактивно настраиваемой продолжительности. 3. Индикатор ClusterBox_Histogramm может использоваться без параллельно работающего сборщика тиков, но это требует периодического удаления временных файлов в папке MQL4\Files. Часть 5. 1. Индикаторы ClusterBox и BearBulBalanceOnTick получили возможность сохранения накопленных данных во временный файл. 2. Изменен алгоритм перемещения прямоугольника, указывающего интервал отображения гистограммы, в индикаторе ClusterBox_Histogramm. 3. Индикатор ClusterBox_Histogramm теперь может отображать силы быков и медведей в разрезе уровней кластеров. 4. Мелкие фиксы в коде ClusterBox_Histogramm. Обновление от 17.09.14 для четвертой и пятой частей Улучшенная версия гистограммы и новый вид гистограммы для просмотра истории - Горизонтальное сечение рынка
rus: Еще бы совместить индикаторы ClusterBox и ClusterBox_Histogramm , чтобы видеть тики как отдельно по каждой свече , так и по группе свечей , которая задается прямоугольником гистограммы. При этом , как в ClusterBox , цифровые записи на графике остаются по каждой свече. Это удобно для анализа.
Nize: Всем привет. Пока заметил что индюк BearBullBalanceOnTicks.mq4 не дружит с TicksCollector_ForcedUpdate.mq4 Прямоугольник в ClusterBox_Histogramm.mq4 живет своей жизнью и наровит все-время перерисоваться там где его не просят. При переключении ТФ границы инициализируются начальными значениями. Это не правильно я думаю. В общем смысл должен быть такой, что куда пользователь его поставил и какие границы задал так он и должен оставаться. Правда предвижу, что в этом случае наверно придется удалять его с графика вручную, ну всяко лучше я думаю. Еще цифры справа от гистограммы наезжают на свечу 0 бара при максимальном увеличении, хорошо бы увеличить отступ, а то нечитабельно. В остальном отличная идея, что можно выбрать любой интервал и по времени и по цене, такого функционала по-моему даже в TOC нет)) Только не понял идею зачем гистограмме встроенный сборщик тиков, ну да ладно.. Сборщик тиков ForceUpdate у меня отлично работает пока и на серваке и на рабочем компе, причем если скопировать файл, то подхватывается без проблем. Единственная мысль возникла сделать файлы по датам, т.е. каждый день новый файл, так удобней конечно, в последствии, если будет развитие, можно подгружать в индюки историю интересующих дней. Теперь что касается практических занятий. Скрытое становится явным, поразительно, вот пример: Можно отчетливо наблюдать, как счетчик тиков зашкаливает, при этом цена практически стоит, образуется доджики, пины и такая площадка, потом бах улетела цена) Что касается гистограммы тиковой в сравнении с синтетической: похоже по цене экстремумы практически совпадают, разница 1..2 пункта, а вот суммарный объем внизу и вверху сильно отличаются, вот скрины: , , Последний скрин из ТОС по реальным объемам. Вроде все тики писалось: Почему такое расхождение и чему верить? И еще пример отработки уровня прошлого дня eur/usd 1,3684: To: Scriptong я откопал у вас индюк который мне подошел, так что отпала необходимость того, о чем я писал, да и тут масса материала надо переварить сперва)
Scriptong: rus пишет: Еще бы совместить индикаторы ClusterBox и ClusterBox_Histogramm , чтобы видеть тики как отдельно по каждой свече , так и по группе свечей , которая задается прямоугольником гистограммы. При этом , как в ClusterBox , цифровые записи на графике остаются по каждой свече. Это удобно для анализа. Их и сейчас можно совмещать. Эти индикаторы не конфликтуют друг с другом. Или Вы имеете в виду какой-то другой вид совмещения?
rus: Scriptong пишет: Или Вы имеете в виду какой-то другой вид совмещения? Нет , просто лучше один индюк запускать сразу , чем несколько. Это предложение и возникло , поскольку оба индикатора очень друг друга дополняют. А то что не конфликтуют , так и хорошо. И , потом , лучше в одном индикаторе задать единые настройки , чем в двух повторять.
Scriptong: Добрый день. Nize пишет: Пока заметил что индюк BearBullBalanceOnTicks.mq4 не дружит с TicksCollector_ForcedUpdate.mq4 В каком смысле? Имеется какой-то конфликт? Или "не дружит" в том плане, что первый индикатор не подтягивает тиковую историю. Если второе, то да - индикатор BearBullBalanceOnTicks не считывает файлы тиковой истории. В ближайших планах есть индикатор расчета дельты. Он уже будет учитывать накопленные данные. Nize пишет: Прямоугольник в ClusterBox_Histogramm.mq4 живет своей жизнью и наровит все-время перерисоваться там где его не просят. Возможно, правая граница прямоугольника установлена на нулевой бар. В этом случае в момент образования новой свечи прямоугольник автоматически перемещается на один бар вправо. Это не баг, так задумано. Другое дело, что сама "задумка" еще хромает. Но это дело времени. Nize пишет: При переключении ТФ границы инициализируются начальными значениями. Это не правильно я думаю. Разные таймфреймы - разные участки. На одном таймфрейме - десять баров, а на другом этот же участок не наберет и одного бара. Это достаточно трудная для решения проблема. Не в техническом плане, а именно на уровне концепции. Nize пишет: Еще цифры справа от гистограммы наезжают на свечу 0 бара при максимальном увеличении, хорошо бы увеличить отступ, а то нечитабельно. А это уже проблема технического плана - в MQL4 на данный момент невозможно сопоставлять длину и высоту текстовых меток со временем и ценой соответственно. Правда, насколько я помню, разработчики МТ4 уже пообещали заняться решением этого вопроса. Так что в будущем вполне возможно будет исправить эту ситуацию к лучшему.
Scriptong: Nize пишет: Только не понял идею зачем гистограмме встроенный сборщик тиков, ну да ладно.. Дело в том, что TicksCollector_ForcedUpdate может быть не запущен пользователем или иметь низкую частоту записи данных в файл. В первом случае гистограмма при переключении таймфрейма потеряет все накопленные данные и придется их заново накапливать. Во втором случае гистограмма может получить не все данные. К примеру, TicksCollector_ForcedUpdate настроен сохранять данные каждые 50 тиков, а переключение таймфрейма гистограммы произошло после 25-и собранных тиков. В итоге тиковый файл на момент чтения гистограммой не досчитывает 25 тиков, которые появятся в нем, но позже. Проблема могла бы решиться синхронизацией работы двух индикаторов (вполне возможно технически), но такой вариант более трудоемок, чем независимый сбор тиков двумя индикаторами. К тому же решается первая проблема (отсутствие запущенного индикатора сборщика тиков).
Scriptong: Nize пишет: Что касается гистограммы тиковой в сравнении с синтетической: похоже по цене экстремумы практически совпадают, разница 1..2 пункта, а вот суммарный объем внизу и вверху сильно отличаются, вот скрины: , , Последний скрин из ТОС по реальным объемам. Вроде все тики писалось: Почему такое расхождение и чему верить? Средний скрин отображает ситуацию на основании величины тиковых объемов, которые предоставляет ДЦ. Первый же скрин - это собранные тики. Мною уже давно замечено, что существует некоторое расхождение в количестве тиков на свечу между собранными данными и теми, которые дает ДЦ. Пока еще не занимался этим вопросом вплотную. Поэтому не могу сказать что-то типа: "Нас обманывают!!!" Скорее всего, в этом нет никакого криминала, т. к. реальная и индикативная истории - это разные вещи. Видимо, такое положение дел нужно попросту принять, ориентируясь на собственноручно собранные тики.
Genry: Scriptong пишет: Мною уже давно замечено, что существует некоторое расхождение в количестве тиков на свечу между собранными данными и теми, которые дает ДЦ. Пока еще не занимался этим вопросом вплотную. Поэтому не могу сказать что-то типа: "Нас обманывают!!!" Скорее всего, в этом нет никакого криминала, т. к. реальная и индикативная истории - это разные вещи. Видимо, такое положение дел нужно попросту принять, ориентируясь на собственноручно собранные тики. Игорь, Вы неоднократно подмечали что тики приходят пачками. Когда-то на mql4 обсуждали эту тему и были сделаны выводы, что: 1. Тики приходят пачками. Бывает, что пачка состоит из одного тика. 2. Советник (или индикатор), состоящий из пустой функции start() выполнится только на первом тике каждой пачки. Остальные тики проигнорируются. Если тик приходит до того как советник (или индикатор) закончит выполнение функции СТАРТ, они его не увидят и будет расхождение в данных, а с учетом того, что тики могут приходить пачками расхождение увеличивается еще больше. 3. При плавающем спреде цена Bid может не меняться, при этом может изменяться цена Ask. И каждый тик - либо изменение цены Ask, либо изменение цены Bid. У ДЦ плавающим спредом он меняется десятки раз в минуту. И это считается нормальным. 4. Официально-обнародованным механизмом контроля 100% тиков MQL4 разработчики называли только DDE, благодаря присутствию в нем накопительного буфера, что гарантировало загрузку всех тиков, исключая случаи потери связи. Вот пару тогдашних обсуждений: Получение котировок по DDE (вопросы) Взаимодействие между MetaTrader 4 и Matlab посредством DDE Котировки в реалтайм.Занятие № 4 (4.1) Получение котировок используя DDE Вариант тикосборщика: Сборщик Тиков SandyEw c MQL5 (авт. Owner) Скрипт на Perl (Sergey Kovalyov), который качает тики с dukascopy, парсит и делает нормальные CSV-файлы (можно в эксель) с тиками. Последний подход интересен тем, что сборка тиков вынесена из МТ и на нее не влияют действия трейдера в терминале.
Scriptong: Genry пишет: Игорь, Вы неоднократно подмечали что тики приходят пачками. Когда-то на mql4 обсуждали эту тему и были сделаны выводы, что: 1. Тики приходят пачками. Бывает, что пачка состоит из одного тика. 2. Советник (или индикатор), состоящий из пустой функции start() выполнится только на первом тике каждой пачки. Остальные тики проигнорируются. Если тик приходит до того как советник (или индикатор) закончит выполнение функции СТАРТ, они его не увидят и будет расхождение в данных, а с учетом того, что тики могут приходить пачками расхождение увеличивается еще больше. 3. При плавающем спреде цена Bid может не меняться, при этом может изменяться цена Ask. И каждый тик - либо изменение цены Ask, либо изменение цены Bid. У ДЦ плавающим спредом он меняется десятки раз в минуту. И это считается нормальным. 4. Официально-обнародованным механизмом контроля 100% тиков MQL4 разработчики называли только DDE, благодаря присутствию в нем накопительного буфера, что гарантировало загрузку всех тиков, исключая случаи потери связи. Так было до этого года. Теперь же, с новым MQL4, механизм изменился. И пока о нем достоверно ничего неизвестно. Косвенным подтверждением появлением нового механизма является тот факт, что сборщик тиков часто регистрирует бОльшее количество тиков, чем указано в объеме свечи. И, кстати, насчет пачки тиков в старом механизме речь шла именно о советниках, т. к. они работают вне интерфейсного потока МТ4. Индикаторы этой участи лишены - им приходится обрабатывать каждый тик.
Scriptong: rus пишет: Нет , просто лучше один индюк запускать сразу , чем несколько. Это предложение и возникло , поскольку оба индикатора очень друг друга дополняют. А то что не конфликтуют , так и хорошо. И , потом , лучше в одном индикаторе задать единые настройки , чем в двух повторять. Совмещения не будет. Это, все-таки, разные индикаторы. Для тех, кому нужно совмещать, существуют шаблоны и профили - один раз настраиваете и потом пользуетесь как одним индикатором.
Scriptong: Вышла новая статья. Ссылка - в шапке темы.
Genry: Игорь, день добрый! Начал изучать работу новых индикаторов. Столкнулся с тем, что отображение индикатора ClusterBox_Histogramm_v2 не такое как в статье. Цвета трех линий сливаются практически в одну. Пример на скрине: http://f5.s.qip.ru/K06fEQKk.png
Scriptong: Genry пишет: Начал изучать работу новых индикаторов. Столкнулся с тем, что отображение индикатора ClusterBox_Histogramm_v2 не такое как в статье. Цвета трех линий сливаются практически в одну. Пример на скрине: http://f5.s.qip.ru/K06fEQKk.png У символа слишком мелкий "один пункт". Пока могу лишь посоветовать делать крупнее масштаб графика или переходить на более мелкий таймфрейм. В процессе тестирования я пытался предугадать такое положение вещей, используя пятизначные символы. В моем случае результат был удовлетворительным. Еще, конечно, многое зависит от текущей рыночной волатильности. Чем она выше, тем меньше пикселей приходится на 1 пункт. P. S. Также на данном этапе еще можно поиграться опцией "Фиксированный масштаб", чтобы можно было разъединить линии объема и сил. Как по-хорошем решать эту проблему, пока не знаю.
Genry: Scriptong пишет: У символа слишком мелкий "один пункт". Это XAUUSD, не подарок конечно для отрисовки . Пока могу лишь посоветовать делать крупнее масштаб графика или переходить на более мелкий таймфрейм. Игорь, на скрине был м15 - оптимальный для торговли на объемах, масштаб обычно максимальный - на рабочем графике еще ClusterBox стоит, но все-равно сливается . Если ТФ сделать меньше, то достаточно быстро новое свойство становится недоступным - гистограмма сил, построенная от начала дня, уходит с графика влево и ее просто не видно. Да, надо что-то придумывать, хочется попробовать идею в торговле. Может добавить коэффициент масштабирования ? PS. Я добавил на пробу 2 коэффициента: ---------------- ShowTrendLine(g_viewRange.leftTime, g_levelsData.price + Point * Kf1, histRightTime, g_levelsData.price + Point * Kf1, price + ". Объем падения: " + IntegerToString(g_levelsData.bearsCnt), i_bearDeltaColor); histRightTime = GetHistRightTime(g_levelsData.bullsCnt, maxVolume); ShowTrendLine(g_viewRange.leftTime, g_levelsData.price + Kf2 * Point * Kf1, histRightTime, g_levelsData.price + Kf2 * Point * Kf1, price + ". Объем роста: " + IntegerToString(g_levelsData.bullsCnt), i_bullDeltaColor); ----------------- График получился вполне приличным http://f5.s.qip.ru/K06fEQKH.png при значениях: input int Kf1 = 8; input int Kf2 = 6; но насколько это удобно И при наведении мышкой на медвежью гистограмму сложно получить данные по тикам, считывается основная гистограмма, с бычьей - порядок.
Scriptong: Genry пишет: Я добавил на пробу 2 коэффициента: Текущее решение, которое у меня есть, пока тоже в этом направлении. Но для этого придется добавлять лишний параметр в индикатор, который не всегда понятен пользователю. Поэтому ищу более интересные варианты. Ну а пока - "правильный ответ" - индикатор ClusterBox_Histogramm_v2_1. Добавлен параметр "Использовать 5-значное представление котировок?", который по умолчанию равен "Да". В этом случае расстояние между линиями гистограмм одного кластера автоматически увеличивается в 10 раз, т. е. до 10 пунктов. Если установить "Нет", то вернемся к варианту второй версии. Новый параметр не влияет на указываемый размер кластера. Так, 5 пунктов на 5-знаке - это 0.5 пункта 4-знака. Косвенное влияние только в том компоненте, что на 5-знаке теперь нельзя установить высоту кластера меньше 30 пунктов.
полная версия страницы