Обсуждение статьи "Универсальный Зигзаг"
Поскольку, наконец, получился ООП-индикатор, то какой смысл вызывать его из советника (iCustom), когда можно создать расчетный объект индикатора в самом советнике и обращаться к вершинам через определенный оператор []? Так и быстрее должно быть.
В исходных данных не хватает тиков. Наверное, все статьи теперь (с появлением быстрой и не бажной реализации CopyTicks) должны учитывать это обстоятельство. Нельзя делать вид, что у нас только бары.
За статью Спасибо. Для новичков, наверное, самое то.
1. Поскольку, наконец, получился ООП-индикатор, то какой смысл вызывать его из советника (iCustom), когда можно создать расчетный объект индикатора в самом советнике и обращаться к вершинам через определенный оператор []? Так и быстрее должно быть.
2. В исходных данных не хватает тиков. Наверное, все статьи теперь (с появлением быстрой и не бажной реализации CopyTicks) должны учитывать это обстоятельство. Нельзя делать вид, что у нас только бары.
3. За статью Спасибо. Для новичков, наверное, самое то.
1. Это неправильная идея. Индикатор работает с использованием индикаторных буферов и параметров rates_total и prev_calculate. Смысл индикатора именно в использовании буферов. В эксперте нет индикаторных буферов, а так же нет rates_total и prev_calculate.
2. Не согласен. Это дело личное. Да и вообще суть только в том, что по тикам надо делать перерасчет на каждом баре.
3. Возникает философский вопрос - кто есть новичок?
1. Это неправильная идея. Индикатор работает с использованием индикаторных буферов и параметров rates_total и prev_calculate. Смысл индикатора именно в использовании буферов. В эксперте нет индикаторных буферов, а так же нет rates_total и prev_calculate.
Почему объект ЗЗ не может быть полноценным источником данных для советника? Плодить разные сущности (разные программы) и соединять их потом через iCustom - уж проще объект прямо в советнике создать. Чем меньше "деталей", тем надежнее "механизм".
Но это, наверное, извечный спор. ООП только его склоняет в одну из сторон еще больше.
2. Не согласен. Это дело личное. Да и вообще суть только в том, что по тикам надо делать перерасчет на каждом баре.
Дали тики, чтобы их игнорить.
3. Возникает философский вопрос - кто есть новичок?
1. Почему объект ЗЗ не может быть полноценным источником данных для советника? Плодить разные сущности (разные программы) и соединять их потом через iCustom - уж проще объект прямо в советнике создать. Чем меньше "деталей", тем надежнее "механизм".
2. Но это, наверное, извечный спор. ООП только его склоняет в одну из сторон еще больше.
3. Дали тики, чтобы их игнорить.
Кому может быть полезна эта статья.1. К решению этой задачи ООП не имеет никакого отношения. К тому же самым полноценным источником данных для советника является индикатор. Советник не дает тех функциональных возможностей по обработке таймсерий, которые дает индикатор.
2. Проблема ООП только в том, что многие взрослые программисты не изучали его в детстве и поэтом испытывают трудности с его пониманием и применением.
3. Где тиковый график? Должен быть тиковый график. Если его нет, создание индикаторов на тиковых графиках, это кустарный процесс.
4. Может быть полезна всем. Это можно сказать квинтэссенция зигзага :) На мой взгляд ценность статьи не в том, что в ней ООП применяется. Часть с ООП это вообще рутинная часть не имеющая, на мой взгляд, особой ценности. А вот начало статьи, где рассматривается создание индикатора по хай/ло и по клоуз стоит прочитать всем (за редким исключением).
1. К решению этой задачи ООП не имеет никакого отношения. К тому же самым полноценным источником данных для советника является индикатор. Советник не дает тех функциональных возможностей по обработке таймсерий, которые дает индикатор.
Хоть бы один аргумент. Единственное, что любят повторять, так это гарантированная подготовка таймсерий в индикаторах при входе в OnCalculate. А в OnTick такой гарантии нет. Она в OnTick всего лишь 99.999999%, а не 100%.
2. Проблема ООП только в том, что многие взрослые программисты не изучали его в детстве и поэтом испытывают трудности с его пониманием и применением.
Индикатор - это объект. ООП так же позволяет создавать объекты. Но только не плодить доп. сущности в виде отдельных программ.
3. Где тиковый график? Должен быть тиковый график. Если его нет, создание индикаторов на тиковых графиках, это кустарный процесс.
Причем тут тиковый график и исходные данные в виде тиков? Советнику вообще плевать, есть графики или нет. И если индикатор в состоянии анализировать историю тиков, значит он построен на тиках. А отсутствие визуализации - это привет ВПС. Т.е. она и не нужна в некоторых ситуациях.
4. Может быть полезна всем. Это можно сказать квинтэссенция зигзага :) На мой взгляд ценность статьи не в том, что в ней ООП применяется. Часть с ООП это вообще рутинная часть не имеющая, на мой взгляд, особой ценности. А вот начало статьи, где рассматривается создание индикатора по хай/ло и по клоуз стоит прочитать всем (за редким исключением).
Хоть бы один аргумент. Единственное, что любят повторять, так это гарантированная подготовка таймсерий в индикаторах при входе в OnCalculate. А в OnTick такой гарантии нет. Она в OnTick всего лишь 99.999999%, а не 100%.
Индикатор - это объект. ООП так же позволяет создавать объекты. Но только не плодить доп. сущности в виде отдельных программ.
Причем тут тиковый график и исходные данные в виде тиков? Советнику вообще плевать, есть графики или нет. И если индикатор в состоянии анализировать историю тиков, значит он построен на тиках. А отсутствие визуализации - это привет ВПС. Т.е. она и не нужна в некоторых ситуациях.
Сразу и сказал - для новичков.Самое сложное -- это написать статью для новичков. Не каждому это под силу.
Ещё сложнее написать статью, которая будет полезной и для новичков и для специалистов.
Было бы неплохо в каждой статье писать для кого статья предназначена. Какие раздела для новичков, какие для специалистов, какие дополняют документацию, перекрёстные ссылки на уже имеющиеся публикации по этой теме и прочее.
Если статья для новичков, то обычно пишут, достаточен ли материал для понимания -- и если могут возникнуть сложности в понимании материала, то с каким материалом перед прочтением лучше познакомиться.
p.s. Из всей технической литературы бестселлерами становятся именно учебники для новичков.
1. Это неправильная идея. Индикатор работает с использованием индикаторных буферов и параметров rates_total и prev_calculate. Смысл индикатора именно в использовании буферов. В эксперте нет индикаторных буферов, а так же нет rates_total и prev_calculate.
Дмитрий, ты здесь не прав. Идея работы с Зиг Загом через класс, минуя iCustom очень правильная. По сути зиг заг это список линий, у каждой из которой есть масса свойств:
- Направление линии (вверх/низ)
- Индекс бара, на котором линия начинается;
- Индекс бара, на котором линия заканчивается;
- Цена начала линии;
- Цена окончания линии;
- Время начала линии;
- Время окончания линии;
- ...
Вместо того, что бы через буфер работать с двухбитной информацией: есть линия/нет линии, нужно создать класс в котором вся возможная информация рассчитывалась автоматически и подавалась удобным образом прямо в эксперт или непосрдественно в индикатор. При этом один единственный класс должен уметь рабоатать с разными типами данных, например с барами, ценами закрытия или тиковым потоком.
Резюмируя: для новичков полезно. Но использование ООП их все равно отпугнет.
p.s. Из всей технической литературы бестселлерами становятся именно учебники для новичков.
Ни один труд для спецов не может стать бестселлером по определению - спецов мало.
На всякий случай, к ним себя не отношу. Статья для ребят, кто только начал осваивать или собирается. Это хорошо.
Чтобы быть правильно понятым, приведу ссылки на две статьи.
- 2016.10.06
- //www.mql5.com/en/users/marketeer">
- www.mql5.com
Дмитрий, ты здесь не прав. Идея работы с Зиг Загом через класс, минуя iCustom очень правильная. По сути зиг заг это список линий, у каждой из которой есть масса свойств:
- Направление линии (вверх/низ)
- Индекс бара, на котором линия начинается;
- Индекс бара, на котором линия заканчивается;
- Цена начала линии;
- Цена окончания линии;
- Время начала линии;
- Время окончания линии;
- ...
1. Вместо того, что бы через буфер работать с двухбитной информацией: есть линия/нет линии, нужно создать класс в котором вся возможная информация рассчитывалась автоматически и подавалась удобным образом прямо в эксперт или непосрдественно в индикатор. При этом один единственный класс должен уметь рабоатать с разными типами данных, например с барами, ценами закрытия или тиковым потоком.
2. Резюмируя: для новичков полезно. Но использование ООП их все равно отпугнет.
1. Да нет. Это всего лишь небольшая доработка к индикатору. Просто статья и так громадного размера получилась. Была идея еще одну статью написать, как раз сделать такое дополнение и рассмотреть класс для решения формул (получался бы зигзаг с функцией распознавания паттернов, формула которых бы записывалась в окне свойств). Но Рашида, что-то не заинтересовала тема. А в одну статью невозможно все впихнуть. Если кто заметил, я там замахнулся еще на один вариант зигзага (по откатам от последнего максимума/минимума), но про него ничего не было в статье.
К тому же в статье все-таки рассматривается способ прямого доступа к значениям вершин. ООП вообще крайне опосредовано относится к данному вопросу, дело вкуса во что обернуть, а решается без ООПа, просто по мере появления вершин, складывать их в дополнительный буфер по порядку, а в начале буфера писать их количество. В этом случае доступ к любой вершин делается в два приема - получение количества вершин, получение заданной вершины от конца. Тут есть небольшие сложности с зигзагом типа как по close (из-за отмены нового луча), но решаемо. Но причем здесь ООП?
2. На случай того, что ООП кого-то отпугнет, статья и сделана из двух частей, до ООП (создание двух индикаторов) - этого достаточно для понимания того, как писать зигзаг.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Универсальный Зигзаг:
Зигзаг — один из самых популярных индикаторов среди пользователей терминала MetaTrader. В статье были проанализированы возможности создания различных вариантов Зигзага. В результате мы получаем универсальный индикатор с широкими возможностями для расширения функциональности, который удобно использовать при разработке торговых советников и других индикаторов.
Для наглядности напишем индикатор, рисующий стрелки при смене направления линии (изменение значения буфера DirectionBuffer) и отмечающий точки на барах, на которых были зафиксированы новые максимумы/минимумы Зигзага (изменение значений буферов LastHighBarBuffer и LastLowBarBuffer). Подробно рассматривать код этого индикатора не будем, в приложении к статье его можно увидеть под названием "iUniZigZagSWEvents". Вид на графике показан на рис. 8.
Рис. 8. Индикатор iUniZigZagSWEvents
Автор: Dmitry Fedoseev