Новый тик или новый бар?

Программирование прибыли: от азов к секретам мастерства. Читайте, спрашивайте, делитесь опытом.
Бонус за сообщение 0.5$
Ответственный Модератор - Haos

Новый тик или новый бар?

Сообщение Haos » 04 июл 2021, 07:53

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

А проблемы могут быть в реальной торговле, в отличие от тестирования. А какие проблемы могут быть?

1. Ошибка в определении нового бара.
Хотя функция может быть и написана правильно, но, чем черт не шутит, по каким-то причинам она может не сработать, или не учесть что-то. Таких функций несколько и частные разработчики тщательно изучали их и в каждом подходе находили "опасные места". При этом странно, что сами разработчики Метатрейдера так и не сделали формализацию прихода нового бара.

2. Новый бар может быть определен правильно, но проблемы возникнут с тиком.
- Тик может не прийти (рынок очень вялый, а ТФ для торговли М5 или меньше);
- тик может прийти, но с опозданием и функция определения нового бара его не распознает;
- тик пришел, но советник не успел выполнить все заложенные действия.

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

3. Банальный разрыв связи интернета аккурат в момент наступления нового бара.
Этот разрыв может быть кратковременным, но этого хватит, чтобы код определения нового бара и запуска выполнения нужных событий не сработал.

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

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

Как известно, процедура для обработки тиков в советнике выглядит так:
Код: выделить все
void OnTick()
{
//----
}

Именно в ней и происходит вся настройка торгового триггера так, чтобы в реальной торговле были выполнены все торговые и аналитические команды.

Другое дело, что надо организовать код так, чтобы когда приход тиков на баре, который не является триггером для торговых операций, советник выполнял минимальный набор проверочных условий. Т.е. буквально: "если на каждом тике нет условий на торговую ситуацию, то сразу же происходит выход из процедуры OnTick()".

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

Пример. Пусть у нас вход в рынок на основе пересечения двух МАшек. Ясно, что анализ пересечения определяется двумя предыдущими барами.
Разработчику нужно написать функцию на получения сигнала от пересечения МАшек, которая, к примеру, возвращает три значения: "UP", "DN", "NO". Первый - сигнал на покупку, второй - на продажу, а третий - нет пересечения.

Тогда, нужно запускать на каждом тике выполнение данной функции и только в случае, если был сигнал, приступать к обработке дальшейших действий. Иначе, просто выходить из функции OnTick().
Да, мы будем в течение всего бара-триггера (когда есть сигнал) получать разрешение для дальнейших команд по нашему алгоритму, но в нем просто нужно будет сделать проверку на, скажем, наличие уже открытой сделки и если она есть, то опять же, выходить из OnTick().

Всё это минимизирует возможные проблемы. У советника будет столько возможностей для правильного входа по сигналу на баре-триггере, сколько придет на нем тиков. Если не получится по какой-то причине выполнить торговый алгоритм на первом тике, будет второй тик, потом третий и т.д. В течение всего бара будет шанс у советника открыть нужную сделку, выставить ордер или закрыть сделку, а часто и открыть и закрыть (если мы говорим, к примеру, о риверсивной ТС).

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

Данная практическая реализация рассмотрена в статье:
Новый тик (пример 1)
Аватар пользователя
Haos
Специалист MQL
 
Сообщений: 24699
Зарегистрирован: 29 мар 2014, 16:07
Средств на руках: 193.70 Доллар
Группа: Главные модераторы
Благодарил (а): 3379 раз.
Поблагодарили: 8200 раз.

Вернуться в MQL – теория и практика

Кто сейчас на форуме?

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 51

Права доступа к форуму

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

cron