Зигзаг в советнике.
Поделитесь кто как реализовывает структуру обработки котировок для советника.
Суть задачи в следующем: в конечном итоге должен быть советник, который торгует на основе зигзага на пробой вершины. Зиг-заг строится по собственному алгоритму.
Суть проблемы: как грамотнее реализовать хранение данных о вершинах зигзага в массиве (цена, время, и т.д.) в советнике с точки зрения достоверности последних (т.е. данных).
Возможные варианты решения:
1) Построение зигзага делается в индикаторе, а в советник данные передаются через iCustom.
- В этом случае как грамотно передать данные о вершинах при пересчете не одного последнего бара, а нескольких (например после обрыва связи, зависания котировок, инициализации индикатора т.п.). Т.е. iCustom нужно вызывать на каждом тике в цикле, где размер цикла - это количество обновленных баров за последний тик. Как определить это количество обновленных баров в советнике?
2) Реализовать весь функционал зиг-зага в советнике.
- Как грамотно в этом случае пересчитывать зиг-заг только для обновленных баров на текущем тике?
Читая вопрос затрудняюсь его понять, во первых если речь идёт о получении данных зигзага советником то лучше получать из индикатора чем рассчитывать весь зигзаг в советнике.
Во вторых причём тут количество обновлённых баров? это не имеет никакого отношения к ТС. Если ТС на пробой уровня пика зигзага то надо просто получить значение последнего пика и бары и тики тут не играют никакой роли.
Постарайтесь понятно сформулировать вопрос так больше вероятность что на него ответят.
уточняю: в советнике мне нужно знать все значение вершин зигзага. Про пробой вершины написал для общего понимания задачи.
Вы услышьте себя. Мне нужно знать все значения вершин ЗЗ.))) Который кстати с ваших слов вы хотите считать сами, по своему алгоритму.
Видимо надо записывать значения вершин в виде номера бара и цены куда нибудь. Это может быть массив, файл, строка.
Вы услышьте себя. Мне нужно знать все значения вершин ЗЗ.))) Который кстати с ваших слов вы хотите считать сами, по своему алгоритму.
Видимо надо записывать значения вершин в виде номера бара и цены куда нибудь. Это может быть массив, файл, строка.
Друзья не надо сводить разговор к обсуждению ТС советника. Естественно что в советнике будут сохранятся все вершины с массиве. А тип массива это класс вершин зигзага. Вопрос и заключаться как оптимально с точки зрения ресурсов передавать значения вершин зигзага в этот массив.
Друзья не надо сводить разговор к обсуждению ТС советника. Естественно что в советнике будут сохранятся все вершины с массиве. А тип массива это класс вершин зигзага. Вопрос и заключаться как оптимально с точки зрения ресурсов передавать значения вершин зигзага в этот массив.
Сложно сказать. Часто пользуюсь одномерными массивами с разными названиями на одинаковый номер пишу номер бара и в другой цену. Мне так удобней. по хорошему нужен 2х мерный массив. Или структура. Структура удобней, поля массива могут иметь только один тип, и если массив целого типа, то и цену придется привести к целому, или если численный, то номер бара тоже будет дабл. В структуре могут быть разные типы данных. По ресурсам примерно одинаково.
Добавлено.
С точки зрения достоверности, смотря что нужно, данные бара по времени не равны тикам их образовавшим.
Если брать стандартный ЗЗ, то лучше брать с индикатора данные, НО если индюк свой, диапазон расчета понятен и задается пользователем, то лучше в советнике, можно даже не рисовать))))) Будет дешевле, чем на всей истории делать расчет. И лучше / проще стат. массивы с запасом, чем динамические, по скромному опыту.
При обрыве связи лучше делать расчет заново. А вот зафиксить обрыв средствами МКЛ сложно. В общем сам считаю просто на каждом баре заново. Мощностей хватает. Для верности делаю расчет 4 раза, а не один.
уточняю: в советнике мне нужно знать все значение вершин зигзага. Про пробой вершины написал для общего понимания задачи.
из индикатора зигзаг можно получить ценовые значения вершин/впадин, как последней так и предыдущих, исчисление идёт вглубь истории 1,2,3.... все вершины Вас наврятли интересуют, их очень много если рассматривать минутный таймфрейм на глубину истории лет так на 30) также можно получить длину колена в пунктах путём разницы пика 1 и 2 например, также можно получить время и OHLC пика и т.п., ну а дальше делать с этими данными что угодно )
Хранить просто так данные индикатора нет смысла, при обрыве и последующем восстановлении связи индикатор сам дорисовывает то что не дорисовал и советник получает эти новые данные в массиве меньше чем за секунду)К сожалению не услышал ничего по существу. Не понятно либо никто не задумывался либо нет желания вникнуть. Для сужения задачи определимся что:
- зигзаг рассчитывается в индикаторе, рассчитанные вершины и последний луч должны передаваться в советник через iCustom;
- iCustom удобнее т.к. расчет зигзага нужен для МТФ - т.е. нужны значения вершин и последнего луча для нескольких таймфреймов;
- количество вершин используемые в советнике для анализа и принятия решения об открытии ордера - последние 20;
- т.к. нужна информации об последнем луче, iCustom вызывается на каждом тике.
Теперь про реализацию.
Индикатор использует стандартный механизм оптимизации расчета в процедуре OnCalculate через сравнение переменных rates_total и prev_calculated
int limit = rates_total - prev_calculated; for(int shift = limit; shift >= 0; shift--) { // расчет зигзага }
Переменная limt может принимать одно из трех значений:
0 - на текущем баре
1 - на смене бара
>1 - пересчет всей истории
При limit == 0 - идет запись в 0-й индекс буферных массивов
При limit == 1 - идет запись в 1-й и 0-й индекс буферных массивов
При limit > 1 - пересчитываются все буферные массивы
Соответственно для считывания достоверных данных о 20-ти последних вершинах и последнем луче зигзага в советнике нужно вызывать iCustom в цикле на каждом тике. Причем если для
limit == 0 - достаточно считать последний бар iCustom(NULL,0,"ZIGZAG,<buffer index>,0);
limit == 1 - нужно считать еще и первый бар iCustom(NULL,0,"ZIGZAG,<buffer index>,1);
limit >1 - нужно считать последние 20 вершин в цикле iCustom(NULL,0,"ZIGZAG,<buffer index>,?); - но мы не знаем сколько баров нужно считать чтобы получить эти 20 вершин, т.е. их нужно считывать до тех пор пока не наберутся эти 20 вершин.
Но мы не знаем индикаторное значение limit из советника. Конечно можно на каждом тике считывать все бары как для варианта при limit >1, но с точки зрения оптимизации это плохо, хотя бы потому что как уже писал нужно будет вызывать iCustom для нескольких ТФ.
Теперь какие мысли хотел услышать и какие варианты приходят на ум:
1) в одном из буферов передавать значение limit - и считывать только нужные индексы в iCustom
2) хранить значение limit в глобальной переменной - и считывать только нужные индексы в iCustom
3) создать отдельный буферный индикатор в котором в последних 20-ти индексах будут храниться значение последних вершин и в iCustom считывать только последние 20 значений.
Вопрос, один как грамотнее вызывать iCustom в разрезе данной постановки задачи?
- www.mql5.com
из индикатора зигзаг можно получить ценовые значения вершин/впадин
Как?
запустить в цикле поиск от нулевого бара до n-ного?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Поделитесь кто как реализовывает структуру обработки котировок для советника.
Суть задачи в следующем: в конечном итоге должен быть советник, который торгует на основе зигзага на пробой вершины. Зиг-заг строится по собственному алгоритму.
Суть проблемы: как грамотнее реализовать хранение данных о вершинах зигзага в массиве (цена, время, и т.д.) в советнике с точки зрения достоверности последних (т.е. данных).
Возможные варианты решения:
1) Построение зигзага делается в индикаторе, а в советник данные передаются через iCustom.
- В этом случае как грамотно передать данные о вершинах при пересчете не одного последнего бара, а нескольких (например после обрыва связи, зависания котировок, инициализации индикатора т.п.). Т.е. iCustom нужно вызывать на каждом тике в цикле, где размер цикла - это количество обновленных баров за последний тик. Как определить это количество обновленных баров в советнике?
2) Реализовать весь функционал зиг-зага в советнике.
- Как грамотно в этом случае пересчитывать зиг-заг только для обновленных баров на текущем тике?