Работа с массивами реальных тиков в структурах MqlTick

MetaTrader 5 обеспечивает возможность работать не только с историей котировок (баров), но и историей реальных тиков. Из пользовательского интерфейса все исторические данные доступны в диалоге Символы. В нем имеются 3 закладки: Спецификация, Бары и Тики. Когда в древовидном списке символов на первой закладке выделен конкретный элемент, при переходе на закладки Бары и Тики можно запросить котировки в виде баров или тиков, соответственно.

Из MQL-программ история реальных тиков также доступна — с помощью функций CopyTicks и CopyTicksRange.  

int CopyTicks(const string symbol, MqlTick &ticks[], uint flags = COPY_TICKS_ALL, ulong from = 0, uint count = 0)

int CopyTicksRange(const string symbol, MqlTick &ticks[], uint flags = COPY_TICKS_ALL, ulong from = 0, ulong to = 0)

Обе функции запрашивают тики для указанного инструмента symbol в передаваемый по ссылке массив ticks. Структура MqlTick содержит всю информацию об одном тике и описана в MQL5 следующим образом:

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

Это потребовалось потому, что у каждого тика всегда заполняются все поля, независимо от того, изменились ли данные по сравнению с предыдущим тиком. Это позволяет всегда иметь актуальное состояние цен на любой момент времени без поиска предыдущих значений по тиковой истории. Например, с тиком могла измениться только цена Bid, но в структуре помимо новой цены будут указаны и остальные параметры: предыдущая цена Ask, Last, объем и так далее.

Вместе с тем, следует иметь в виду, что в зависимости от типа инструмента некоторые поля в тиках могут быть всегда нулевыми (и для них никогда не взводятся соответствующие биты маски). В частности, для инструментов Forex, как правило, остаются пустыми поля last, volume, volume_real.  

Приемный массив ticks может быть фиксированного размера или динамический. В фиксированный массив функции скопируют не больше тиков, чем размер массива, невзирая на реальное количество тиков в запрошенном интервале времени (указанном параметрами from/to в функции CopyTicksRange) или в параметре count функции CopyTicks. В массиве ticks наиболее старые тики размещаются под первыми номерами, а наиболее новые — под последними.

В параметрах обеих функций временные отсчеты задаются в виде миллисекунд, прошедших с 01.01.1970 00:00:00. Так в функции CopyTicks диапазон запрашиваемых тиков задается начальным отсчетом from и количеством тиков count, а в функции CopyTicksRange — начальным и конечным отсчетами from и to (обе границы — включительно).

Иными словами, CopyTicksRange предназначена для получения тиков в конкретном интервале, причем их количество заранее не известно. А CopyTicks гарантирует получение не более count тиков, но не позволяет заранее определить, какой временной интервал эти тики покроют.

Хронологический порядок значений from и to в CopyTicksRange неважен: функция в любом случае отдаст тики, начиная от минимального из двух значений и заканчивая максимальным.

Функция CopyTicks расценивает параметр from как левую границу с минимальным временем и отсчитывает от неё count тиков в будущее. Однако существует важное исключение: значение from = 0 (по умолчанию) трактуется как текущий момент времени, и от него тики отсчитываются в прошлое. Это дает возможность всегда получить заданное количество последних тиков. Когда параметр count = 0 (по умолчанию), функция копирует не более 2000 тиков.

Обе функции возвращают количество скопированных тиков либо -1 в случае ошибки. В частности GetLastError может возвращать следующие коды ошибок:

• ERR_HISTORY_TIMEOUT — время ожидания синхронизации тиков вышло, функция отдала всё что было;
• ERR_HISTORY_SMALL_BUFFER — статический буфер слишком маленький, отдано столько, сколько поместилось в массив;
• ERR_NOT_ENOUGH_MEMORY — не удалось выделить нужный объем памяти для получения истории тиков из указанного диапазона в динамический массив.

Параметр flags определяет тип запрашиваемых тиков.

При любом типе запроса в оставшиеся поля структуры MqlTick, не соответствующие флагам, подставляются предыдущие актуальные значения. Например, если запрашивались только информационные тики (COPY_TICKS_INFO), в них все равно будут заполнены остальные поля — так, если изменилась только цена Bid, в поля ask и volume будут записаны последние известные значения. Чтобы узнать, что именно новое содержит тик, необходимо анализировать его поле flags (там будет либо значение TICK_FLAG_BID, либо TICK_FLAG_ASK, либо их комбинация). Если тик имеет нулевые значения цен Bid и Ask, и при этом флаги показывают, что данные цены изменились (flags == TICK_FLAG_BID | TICK_FLAG_ASK), то это говорит об опустошении стакана заявок.

Аналогичным образом, если запрашивались торговые тики (COPY_TICKS_TRADE), в их поля bid и ask будут записаны последние известные значения цен. В данном случае поле flags может иметь комбинацию значений TICK_FLAG_LAST, TICK_FLAG_VOLUME, TICK_FLAG_BUY, TICK_FLAG_SELL.

При запросе COPY_TICKS_ALL отдаются все тики.

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

Тиковые данные имеют значительно больший размер, чем минутные котировки. При первом запросе истории тиков или запуске тестирования по реальным тикам их скачивание может занять продолжительное время. История тиковых данных хранится в файлах внутреннего TKC-формата в каталоге {каталог_терминала}/bases/{имя_сервера}/ticks/{имя_символа}. Каждый файл содержит информацию за один месяц.

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

В экспертах и скриптах функции могут дожидаться результата до 45 секунд: в отличие от индикатора каждый эксперт и скрипт работает в собственном потоке, и поэтому может дожидаться окончания синхронизации в пределах таймаута. Если за это время тики так и не будут синхронизированы в необходимом объёме, то будут возвращены только имеющиеся в наличии тики, а синхронизация продолжится в фоновом режиме.

Напомним, что тики, поступающие в режиме реального времени, транслируются на графики в виде событий: индикаторы получают уведомления о новых тиках в обработчике OnCalculate, а эксперты — в обработчике OnTick. При этом следует иметь в виду, что система не гарантирует доставку всех событий: если за то время, пока программа обрабатывает текущее событие OnCalculate/OnTick, в терминал поступили новые тики, события о них для этой "занятой" программы не формируются и не добавляются в её очередь (см. раздел Обзор функций обработки событий). Более того, в терминал может одновременно прийти несколько тиков, но для каждой MQL-программы будет сгенерировано лишь одно событие — об актуальном состоянии рынка. В связи с этим весьма полезной является функция CopyTicks, которая позволяет запрашивать все тики, пришедшие с момента предыдущей обработки события. Вот как выглядит этот алгоритм в псевдокоде:

Функция SymbolInfoTick, использованная здесь, заполняет передаваемую по ссылке одиночную структуру MqlTick информацией о последнем тике. Мы изучим её в отдельном разделе.

Обратите внимание, что при вызове CopyTicks к старой метке времени prev добавляется одна миллисекунда. Это гарантирует, что прежний тик не будет обработан повторно. Однако, если в течение одной миллисекунды, соответствующей prev, на самом деле было несколько тиков, данный алгоритм пропустит их. Если требуется охватить абсолютно все тики, нужно запоминать количество имеющихся тиков с временем prev одновременно с обновлением переменной prev. Затем при следующем вызове CopyTicks следует запрашивать тики с момента prev и пропускать (игнорировать в массиве) сохраненное количество "старых" тиков.

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

Для демонстрации функций рассмотрим два примера — по одному на каждую функцию. Для обоих примеров был разработан общий заголовочный файл TickEnum.mqh, в котором вышеприведенные константы для флагов запрашиваемых тиков и флагов состояния тиков сведены в два перечисления.

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

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

Во входных параметрах можно задать рабочий символ (по умолчанию, символ графика), количество анализируемых тиков и режим запроса из COPY_TICKS.

Статистика встречаемости каждого флага (а точнее, каждого бита в битовой маске) в свойствах тиков собирается в структуре TickFlagStats.

В функции OnStart описан массив структур TickFlagStats размером в 8 элементов: 6 из них (с 1 по 6 включительно) используются для соответствующих TICK_FLAG-битов, а два остальных для комбинаций битов (см. далее). С помощью простого цикла в массиве заполняются элементы для отдельных стандартных битов/флагов, а после цикла — две комбинированных маски (в 0-м элементе будут подсчитываться тики с одновременным изменением Bid и Ask, а в 7-м элементе — тики с одновременными сделками Buy и Sell).

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

Наибольший интерес, конечно, представляет сама функция CalcTickStats.

Её назначение запросить с помощью CopyTicks тики указанного символа (symbol), конкретного типа (type), начиная с даты start, в количестве count штук. Параметр start, будучи типа datetime, должен пересчитываться в миллисекунды при передаче в CopyTicks. Напомним, что если start = 0 (что имеет место в нашем случае, в функции OnStart), система вернет последние тики, то есть отсчет ведется от текущего времени. Поэтому при каждом вызове скрипта статистика, скорее всего, будет обновляться за счет прихода новых тиков. Исключение могут составить лишь запросы на выходных или малоликвидных инструментах.

Если CopyTicks выполнилась без ошибок, наш код выводит в журнал временной диапазон, покрытый полученными тиками.

Наконец, в цикле мы проходим по всем тикам и подсчитываем количество побитовых совпадений во флагах тиков и масках элементов в подготовленном заранее массиве статистических структур TickFlagStats.

Желательно запускать скрипт на инструментах, где имеется информация о реальных объемах и сделках, чтобы протестировать все режимы из перечисления COPY_TICKS (напомним, они соответствуют константам для параметра flags в CopyTicks: COPY_TICKS_INFO, COPY_TICKS_TRADE и COPY_TICKS_ALL).

Вот пример записей в журнале при запросе статистики для 100000 тиков всех типов (TickType = ALL_TICKS):

А вот что получится, если запросить только информационные тики (TickType = INFO_TICKS).

Здесь можно проверить точность расчетов: сумма чисел для "TF_BID" и "TF_ASK" за вычетом совпадений "TF_BID_ASK (COMBO)" дает ровно 100000 (общее количество тиков). Тики с объемами и ценой Last в результат не попали ни разу, как и ожидалось.

Теперь запустим скрипт еще раз — исключительно для торговых тиков (TickType = TRADE_TICKS).

Все тики имели флаги "TF_LAST" и "TF_VOLUME", а смешивание направлений сделок случилось 7308 раз. Опять же сумма показателей "TF_BUY" и "TF_SELL" за вычетом их комбинации совпадает с общим количеством тиков.

Второй скрипт SeriesTicksDeltaVolume.mq5 использует функцию CopyTicksRange для расчета дельт объемов на каждом баре. Как известно, котировки MetaTrader 5 содержат лишь обезличенные объемы, в которых покупки и продажи объединены в одной величине для каждого бара. Однако наличие истории реальных тиков позволяет посчитать отдельно суммы объемов покупок и продаж, а также их разницу. Данные характеристики являются дополнительными важными факторами для принятия торговых решений.

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

Статистика по каждому бару хранится в структуре DeltaVolumePerBar.

В функции OnStart описан массив таких структур, его размер выделяется под указанное количество баров.

А вот и основной алгоритм.

В цикле по барам получаем временные рамки для каждого бара: prev и next (0-й неполный бар не обрабатывается). Вызываем CopyTicksRange для этого интервала, не забывая перевести datetime в миллисекунды и вычесть 1 миллисекунду из правой границы, так как это время принадлежит уже следующему бару. В отсутствие ошибок обрабатываем в цикле массив полученных тиков.

Если в настройках скрипта запрашивался анализ по торговым тикам (TRADE_TICKS), проверяем наличие флагов TICK_FLAG_BUY и TICK_FLAG_SELL, и если хотя бы один из них взведен, учитываем объем из поля volume в соответствующей переменной структуры DeltaVolumePerBar. Данный режим подходит только для биржевых инструментов. Для инструментов Forex объемы и флаги направлений сделок не заполняются, а потому следует изобрести другой подход.

Если в настройках указаны информационные тики (INFO_TICKS), которые есть для всех инструментов, алгоритм строится на следующих эмпирических правилах. Как известно, покупки толкают цену вверх, а продажи — вниз. Поэтому можно предположить, что если средняя цена Ask+Bid двинулась в новом тике вверх относительно предыдущего, то на нем произошла покупка, а если цена двинулась вниз — продажа. Объем можно примерно оценить как количество пройденных пунктов (_Point).

Результаты подсчетов выводятся просто как массив структур с собранной статистикой.

Ниже показана пара фрагментов журналов для режимов TRADE_TICKS и INFO_TICKS.

Значения, конечно, существенно разные, но дело не в абсолютных величинах: в отсутствие биржевых объемов даже такая эмуляция расщепления и динамика дельт позволяет взглянуть на поведение рынка под другим углом.

Когда мы научимся создавать индикаторы, то сможем встроить этот алгоритм в один из них (см. пример IndDeltaVolume.mq5 в разделе Ожидание данных и управление видимостью), чтобы наглядно отобразить дельты непосредственно на графике.