Программирование на MQL5 для трейдеровРасширенные средства языкаЭкономический календарьПеренос базы календаря в тестер

Скачать одним файлом:

Перенос базы календаря в тестер

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

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

Внимание! При запросе данных календаря в терминале время всех событий сообщается с учетом текущей временной зоны сервера, включая и возможную поправку на "летнее" время (как правило, это означает увеличение меток времени на 1 час). Это синхронизирует выпуск новостей со временем котировок в режиме онлайн. Однако прошлые переводы часов (полгода, год назад и более) отображаются только в котировках, но не в событиях календаря. Вся база календаря считывается через MQL5 по текущему часовому поясу сервера. Из-за этого любой создаваемый архив календаря будет содержать корректные временные метки для тех событий, которые происходили при том же режиме DST (включенном или выключенном), что был активен в момент сохранения. Для событий в "противоположных" "полугодиях" требуется самостоятельно делать поправку на час после чтения архива. В рассматриваемых далее примерах этот нюанс опущен.

Назовем класс кэша CalendarCache и поместим его в файл CalendarCache.mqh. Нам потребуется сохранять в файле все 3 таблицы базы календаря (MqlCalendarCountry, MqlCalendarEvent, MqlCalendarValue). Напомним, что MQL5 предоставляет функции FileWriteArray и FileReadArray (см. Запись и чтение массивов), способные напрямую писать и считывать массивы простых структур в файлы. Однако 2 из 3 структур в нашем случае не являются простыми, поскольку в них имеются строковые поля. Поэтому нам потребуется механизм отдельного сохранения строк, похожий на тот, что мы уже использовали в классе CalendarFilter (там был массив строк stringCache, а в фильтрах указывался индекс нужной строки из этого массива).

Чтобы не перемешивать строки из разных "календарных" структур в одном "словаре" мы подготовим шаблонный класс StringRef: параметром-типом T будет выступать любая из MqlCalendar-структур. За счет этого мы получим отдельный кэш строк для стран, и отдельный кэш строк для видов событий.

template<typename T>
struct StringRef
{
   static string cache[];
   int index;
   StringRef(): index(-1) { }

   void operator=(const string s)
   {
      if(index == -1)
      {
         PUSH(cache, s);
         index = ArraySize(cache) - 1;
      }
      else
      {
         cache[index] = s;
      }
   }

   string operator[](int x = 0) const
   {
      if(index != -1)
      {
         return cache[index];
      }
      return NULL;
   }

   static bool save(const int handle)
   {
      FileWriteInteger(handle, ArraySize(cache));
      for(int i = 0; i < ArraySize(cache); ++i)
      {
         FileWriteInteger(handle, StringLen(cache[i]));
         FileWriteString(handle, cache[i]);
      }
      return true;
   }

   static bool load(const int handle)
   {
      const int n = FileReadInteger(handle);
      for(int i = 0; i < n; ++i)
      {
         PUSH(cache, FileReadString(handle, FileReadInteger(handle)));
      }
      return true;
   }
};

template<typename T>
static string StringRef::cache[];

Сами строки "складируются" в массиве cache с помощью operator=, и извлекаются из него с помощью operator[] (с фиктивным индексом, который всегда опущен). В каждом объекте хранится лишь индекс строки в массиве. Массив cache объявлен статическим, так что будет аккумулировать все строковые поля одной структуры T. Желающие могут поменять принцип кэширования таким образом, чтобы каждое поле структуры имело свой массив, но нам это не принципиально.

Запись массива в файл и чтение из файла выполняются парой статических методов save и load: оба принимают в качестве параметра дескриптор файла.

С учетом класса StringRef опишем структуры, дублирующие стандартные структуры календаря, но в которых вместо строковых полей используются объекты StringRef. Например, для MqlCalendarCountry получим MqlCalendarCountryRef. Стандартная и модифицированная структуры копируются друг в друга также перегруженными операторами '=' и '[]'.

   struct MqlCalendarCountryRef
   {
      ulong id;
      StringRef<MqlCalendarCountry> name;
      StringRef<MqlCalendarCountry> code;
      StringRef<MqlCalendarCountry> currency;
      StringRef<MqlCalendarCountry> currency_symbol;
      StringRef<MqlCalendarCountry> url_name;

      void operator=(const MqlCalendarCountry &c)
      {
         id = c.id;
         name = c.name;
         code = c.code;
         currency = c.currency;
         currency_symbol = c.currency_symbol;
         url_name = c.url_name;
      }

      MqlCalendarCountry operator[](int x = 0) const
      {
         MqlCalendarCountry r;
         r.id = id;
         r.name = name[];
         r.code = code[];
         r.currency = currency[];
         r.currency_symbol = currency_symbol[];
         r.url_name = url_name[];
         return r;
      }
   };

Обратите внимание, что в операторах присваивания первого метода работает перегрузка '=' из StringRef, за счет чего все строки попадают в массив StringRef<MqlCalendarCountry>::cache. Во втором методе вызовы оператора '[]' невидимым образом получают адрес строки и возвращают из StringRef непосредственно строку, хранящуюся по этому адресу в массиве cache.

Структура MqlCalendarEventRef определена похожим образом, но в ней всего 3 поля (source_url, event_code, name) требуют замены типа string на StringRef<MqlCalendarEvent>. Структура MqlCalendarValue подобных преобразований не требует, так как в ней нет строковых полей.

На этом подготовительные этапы завершены, и можно приступать к основному рабочему классу кэша CalendarCache.

Исходя из общих соображений, а также для совместимости с уже разработанным классом CalendarFilter опишем в кэше поля, задающие контекст (страну или валюту), диапазон дат хранимых событий, и момент генерации кэша (время X, переменная t).

class CalendarCache
{
   string context;
   datetime from, to;
   datetime t;
   ...

public:
   CalendarCache(const string _context = NULL,
      const datetime _from = 0, const datetime _to = 0):
      context(_context), from(_from), to(_to), t(0)
   {
      ...
   }

В принципе, прописывать ограничения при создании кэша из календаря не имеет особого смысла: более практичным, вероятно, является полный кэш, так как его размер не является критичным — пара десятков мегабайт на середину 2022 года (это история с 2007 года и планируемые события до 2024). Впрочем, ограничения могут пригодиться для демонстрационных программ с искусственно урезанным функционалом.

Очевидно, что в кэше следует предусмотреть массивы календарных структур для хранения всех данных.

   MqlCalendarValue values[];
   MqlCalendarEvent events[];
   MqlCalendarCountry countries[];
   ...

Изначально они заполняются из базы календаря методом update.

   bool update()
   {
      string country = NULL, currency = NULL;
      if(StringLen(context) == 3)
      {
         currency = context;
      }
      else if(StringLen(context) == 2)
      {
         country = context;
      }

      Print("Reading online calendar base...");

      if(!PRTF(CalendarValueHistory(values, from, to, country, currency))
         || (currency != NULL ?
            !PRTF(CalendarEventByCurrency(currency, events)) :
            !PRTF(CalendarEventByCountry(country, events)))
         || !PRTF(CalendarCountries(countries)))
      {
         // объект не готов, t = 0
      }
      else
      {
         t = TimeTradeServer();
      }
      return (bool)t;
   }

Признаком работоспособности кэша выступает поле t со временем заполнения массивов.

Объект заполненного кэша можно записать в файл с помощью метода save. В начале файла идет заголовок CALENDAR_CACHE_HEADER — это строка "MQL5 Calendar Cache\r\nv.1.0\r\n", позволяющая убедиться при чтении в правильности формата. Далее сохраняются переменные context, from, to и t, а также массив values "как есть". Перед самим массивом мы записываем его размер, чтобы восстановить его при чтении.

   bool save(string filename = NULL)
   {
      if(!t) return false;

      MqlDateTime mdt;
      TimeToStruct(t, mdt);
      if(filename == NULL) filename = "calendar-" +
         StringFormat("%04d-%02d-%02d-%02d-%02d.cal",
         mdt.year, mdt.mon, mdt.day, mdt.hour, mdt.min);
      int handle = PRTF(FileOpen(filename, FILE_WRITE | FILE_BIN));
      if(handle == INVALID_HANDLE) return false;

      FileWriteString(handle, CALENDAR_CACHE_HEADER);
      FileWriteString(handle, context, 4);
      FileWriteLong(handle, from);
      FileWriteLong(handle, to);
      FileWriteLong(handle, t);
      FileWriteInteger(handle, ArraySize(values));
      FileWriteArray(handle, values);
      ...

С массивами events и countries в дело вступают наши структуры-"обертки" с суффиксом "Ref". Вспомогательный метод store конвертирует массив events в массив простых структур erefs, в которых строки заменены на номера в "словаре" строк StringRef<MqlCalendarEvent>. Такие простые структуры уже можно обычным способом записать в файл, но для их последующего чтения требуется также сохранить все строки "словаря" (вызов StringRef<MqlCalendarEvent>::save(handle)). Структуры стран преобразуются и сохраняются в файл аналогичным образом.

      MqlCalendarEventRef erefs[];
      store(erefs, events);
      FileWriteInteger(handle, ArraySize(erefs));
      FileWriteArray(handle, erefs);
      StringRef<MqlCalendarEvent>::save(handle);

      MqlCalendarCountryRef crefs[];
      store(crefs, countries);
      FileWriteInteger(handle, ArraySize(crefs));
      FileWriteArray(handle, crefs);
      StringRef<MqlCalendarCountry>::save(handle);

      FileClose(handle);
      return true;
   }

Упомянутый метод store довольно прост: в нем в цикле по элементам выполняется перегруженный оператор присваивания в структурах MqlCalendarEventRef или MqlCalendarCountryRef.

   template<typename T1,typename T2>
   void static store(T1 &array[], T2 &origin[])
   {
      ArrayResize(array, ArraySize(origin));
      for(int i = 0; i < ArraySize(origin); ++i)
      {
         array[i] = origin[i];
      }
   }

Для загрузки полученного файла в объект кэша написан "зеркальный" метод load. Он в том же порядке читает данные из файла в переменные и массивы, попутно выполняя обратные преобразования строковых полей для видов событий и стран.

   bool load(const string filename)
   {
      Print("Loading calendar cache ", filename);
      t = 0;
      int handle = PRTF(FileOpen(filename, FILE_READ | FILE_BIN));
      if(handle == INVALID_HANDLE) return false;

      const string header = FileReadString(handle, StringLen(CALENDAR_CACHE_HEADER));
      if(header != CALENDAR_CACHE_HEADER) return false; // не наш формат

      context = FileReadString(handle, 4);
      if(!StringLen(context)) context = NULL;
      from = (datetime)FileReadLong(handle);
      to = (datetime)FileReadLong(handle);
      t = (datetime)FileReadLong(handle);
      Print("Calendar cache interval: ", from, "-", to);
      Print("Calendar cache saved at: ", t);
      int n = FileReadInteger(handle);
      FileReadArray(handle, values, 0, n);

      MqlCalendarEventRef erefs[];
      n = FileReadInteger(handle);
      FileReadArray(handle, erefs, 0, n);
      StringRef<MqlCalendarEvent>::load(handle);
      restore(events, erefs);

      MqlCalendarCountryRef crefs[];
      n = FileReadInteger(handle);
      FileReadArray(handle, crefs, 0, n);
      StringRef<MqlCalendarCountry>::load(handle);
      restore(countries, crefs);

      FileClose(handle);
      ... // здесь будет кое-что еще
   }

Вспомогательный метод restore использует в цикле по элементам перегрузку оператора '[]' в структурах MqlCalendarEventRef или MqlCalendarCountryRef, чтобы по номеру строки получить саму строку и присвоить её в стандартную структуру MqlCalendarEvent или MqlCalendarCountry.

   template<typename T1,typename T2>
   void static restore(T1 &array[], T2 &origin[])
   {
      ArrayResize(array, ArraySize(origin));
      for(int i = 0; i < ArraySize(origin); ++i)
      {
         array[i] = origin[i][];
      }
   }

Уже на этом этапе мы могли бы написать на основе класса CalendarCache простой тестовый индикатор, запустить его на онлайн-чарте и сохранить в файл с кэшем календаря. Затем файл можно было бы загрузить из копии индикатора в тестере и получить полный набор событий. Однако для практических разработок этого недостаточно.

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

Суть индексирования легко понять, если представить, как в нашем кэше эффективно реализовать аналоги стандартных функций календаря. Например, в функцию CalendarValueById передается идентификатор события. Прямой перебор записей в массиве values был бы очень затратным по времени. Поэтому требуется дополнить массив некоторой "структурой данных", которая позволила бы оптимизировать поиск. "Структура данных" взята в кавычки, потому что речь не о сущности языка программирования (struct), а в целом об архитектуре построения данных — она может состоять из разных частей и основываться на разных организационных принципах. Разумеется, дополнительные данные потребуют памяти, но обмен памяти на скорость — обычное явление в программировании.

Наиболее простым решением для индексирования выступает отдельный двумерный массив, отсортированный по возрастанию, так что к нему можно применить быстрый поиск с помощью функции ArrayBsearch. По второму измерению достаточно двух элементов: значения с индексами [i][0], по которым и выполняется сортировка, содержат идентификаторы, а значения [i][1] — порядковые позиции в массиве структур.

Также часто применяется хэширование — преобразование исходных значений в некие ключи (хэши, целые числа) таким образом, что это обеспечивает минимальное количество коллизий (совпадений ключей для разных исходных данных). Фундаментальное свойство ключей — близкое к равномерному случайное распределение их значений, за счет чего они могут использоваться как индексы в заранее распределенных массивах ("корзинах"). Вычисление хэш-функции для одного элемента исходных данных — это быстрый процесс, который фактически выдает адрес самого элемента. По такому принципу, в частности, работают известные "структуры данных" хэш-карты (hashmap).

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

Для демонстрации мы используем в классе CalendarCache оба подхода: хэширование и бинарный поиск.

В поставку MetaTrader 5 входит набор классов для создания хэш-карт (MQL5/Include/Generic/HashMap.mqh), но мы обойдемся собственной более простой реализацией, в которой останется только принцип использования хэш-функции.

Схема индексации данных путем хэширования

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

   int id4country[];
   int id4event[];
   int id4value[];

В их элементах будет храниться порядковый номер записи в соответствующем массиве (countries, events, values).

Под каждый из массивов "переадресации" следует выделить как минимум в 2 раза больше элементов, чем количество соответствующих структур в базе (и в кэше) календаря. За счет этой избыточности мы минимизируем количество коллизий при хэшировании. Считается, что наибольшая эффективность достигается при выборе размера, равного простому числу. Поэтому в классе имеется статический метод size2prime, возвращающий рекомендованный размер массива хэш-"корзинок" (одного из id4-массивов) по количеству элементов в исходных данных.

   static int size2prime(const int size)
   {
      static int primes[] =
      {
        17, 53, 97, 193, 389,
        769, 1543, 3079, 6151,
        12289, 24593, 49157, 98317,
        196613, 393241, 786433, 1572869,
        3145739, 6291469, 12582917, 25165843,
        50331653, 100663319, 201326611, 402653189,
        805306457, 1610612741
      };

      const int pmax = ArraySize(primes);
      for(int p = 0; p < pmax; ++p)
      {
         if(primes[p] >= 2 * size)
         {
            return primes[p];
         }
      }
      return size;
   }

Весь процесс хэширования календаря описан в методе hash. Рассмотрим его начало на примере массива структур countries, а два остальных массива обрабатываются аналогично.

Итак, мы получаем рекомендованный "простой" размер индекса id4country из размера массива countries, вызвав size2prime. Изначально индексный массив заполняется значением -1, то есть всего его элементы свободны. Далее в цикле по странам необходимо вычислить хэш для каждого очередного идентификатора страны и найти по нему свободный индекс в массиве id4country. Этим занимается вспомогательный метод place.

   bool hash()
   {
      Print("Hashing calendar...");
      ...
      const int c = PRTF(ArraySize(countries));
      PRTF(ArrayResize(id4country, size2prime(c)));
      ArrayInitialize(id4country, -1);

      for(int i = 0; i < c; ++i)
      {
         if(place(countries[i].id, i, id4country) == -1)
         {
            return false; // неудача
         }
      }
      ...
      return true; // успех
   }

В качестве хэш-функции внутри place используется выражение: (MathSwap(id) ^ 0xEFCDAB8967452301) % n, где id — это наш идентификатор, а n — размер индексного массива. Таким образом, результат вычислений всегда приводится к валидному индексу внутри array[]. Принцип выбора хэш-функции — это отдельная тема, выходящая за рамки книги.

   int place(const ulong id, const int index, int &array[])
   {
      const int n = ArraySize(array);
      int p = (int)((MathSwap(id) ^ 0xEFCDAB8967452301) % n); // хэш-функция
      int attempt = 0;
      while(array[p] != -1)
      {
         if(++attempt > n / 10) // количество коллизий - не больше 1/10 от количества
         {
            return -1; // ошибка записи в индексный массив
         }
         p = (p + attempt) % n;
      }
      array[p] = index;
      return p;
   }

Если ячейка под номером p в индексном массиве не занята (равна -1), мы сразу же записываем в элемент [p] адрес размещения "календарной" структуры. Если ячейка уже занята, пытаемся выбрать следующую по формуле p = (p + attempt) % n, где attempt — счетчик попыток (это наш закамуфлированный вариант списка элементов с совпавшим хэшем). Если количество неудачных попыток достигнет одной десятой части исходных данных, индексирование завершится ошибкой, но такое практически исключено при нашем выбранном с запасом размере индексного массива и известной природе хэшируемых данных (уникальных идентификаторов).

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

   template<typename S>
   int find(const ulong id, const int &array[], const S &structs[])
   {
      const int n = ArraySize(array);
      if(!n) return false;
      int p = (int)((MathSwap(id) ^ 0xEFCDAB8967452301) % n); // хэш-функция
      int attempt = 0;
      while(structs[array[p]].id != id)
      {
         if(++attempt > n / 10)
         {
            return -1; // ошибка извлечения из индексного массива
         }
         p = (p + attempt) % n;
      }
      return array[p];
   }

Покажем, как это используется на практике. Среди стандартных функций календаря есть, в частности, CalendarCountryById и CalendarEventById. Когда потребуется протестировать какую-либо MQL-программу в тестере, она не сможет напрямую обратиться к ним, но зато сможет загрузить кэш календаря в объект CalendarCache, и потому в нем должны быть аналогичные методы.

   bool calendarCountryById(ulong country_id, MqlCalendarCountry &cnt)
   {
      const int index = find(country_id, id4country, countries);
      if(index == -1) return false;

      cnt = countries[index];
      return true;
   }

   bool calendarEventById(ulong event_id, MqlCalendarEvent &event)
   {
      const int index = find(event_id, id4event, events);
      if(index == -1) return false;

      event = events[index];
      return true;
   }

Они как раз и используют метод find и индексные массивы id4country и id4event.

Но это не самые востребованные возможности календаря. Гораздо чаще MQL-программа с новостной стратегией нуждается в функциях CalendarValueHistory, CalendarValueHistoryByEvent, CalendarValueLast или CalendarValueLastByEvent. С помощью них обеспечивается быстрый доступ к записям календаря по времени, по стране или валюте.

Значит, класс CalendarCache должен предоставить аналогичные методы. И здесь мы воспользуемся вторым методом "индексирования" — через двоичный поиск в отсортированном массиве.

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

   ulong value2event[][2];    // [0] - event_id, [1] - value_id
   ulong value2country[][2];  // [0] - country_id, [1] - value_id
   ulong value2currency[][2]; // [0] - currency ushort[4]<->long, [1] - value_id
   ulong value2time[][2];     // [0] - time, [1] - value_id

В первом элементе каждого ряда, то есть под индексами [i][0] будет записываться идентификатор события, страны, валюты или время, соответственно. Во втором элементе ряда, под индексами [i][1] разместятся идентификаторы конкретных новостей. После однократного заполнения всех массивов они сортируются с помощью ArraySort по значениям [i][0]. Затем мы сможем искать по идентификатору, например, события event_id все такие новости в массиве value2event: функция ArrayBsearch вернет номер первого подходящего элемента, за которым будут следовать остальные с таким же event_id, пока не встретится отличный идентификатор. Порядок во второй "колонке" не определен (может быть любым).

Быстрый поиск связанных структур на основе сортировки

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

   bool bind()
   {
      Print("Binding calendar tables...");
      const int n = ArraySize(values);
      ArrayResize(value2event, n);
      ArrayResize(value2country, n);
      ArrayResize(value2currency, n);
      ArrayResize(value2time, n);
      for(int i = 0; i < n; ++i)
      {
         value2event[i][0] = values[i].event_id;
         value2event[i][1] = values[i].id;

         const int e = find(values[i].event_id, id4event, events);
         if(e == -1) return false;

         value2country[i][0] = events[e].country_id;
         value2country[i][1] = values[i].id;

         const int c = find(events[e].country_id, id4country, countries);
         if(c == -1) return false;

         value2currency[i][0] = currencyId(countries[c].currency);
         value2currency[i][1] = values[i].id;

         value2time[i][0] = values[i].time;
         value2time[i][1] = values[i].id;
      }
      ArraySort(value2event);
      ArraySort(value2country);
      ArraySort(value2currency);
      ArraySort(value2time);
      return true;
   }

В случае валют в качестве идентификатора берется специальное число, получаемое из строки функцией currencyId.

   static ulong currencyId(const string s)
   {
      union CRNC4
      {
         ushort word[4];
         ulong ul;
      } v;
      StringToShortArray(s, v.word);
      return v.ul;
   }

Теперь мы можем, наконец, целиком представить конструктор класса CalendarCache.

   CalendarCache(const string _context = NULL,
      const datetime _from = 0, const datetime _to = 0):
      context(_context), from(_from), to(_to), t(0), eventId(0)
   {
      if(from > to) // метка того, что context - это имя файла
      {
         load(_context);
      }
      else
      {
         if(!update() || !hash() || !bind())
         {
            t = 0;
         }
      }
   }

При запуске на онлайн-чарте созданный объект с параметрами по умолчанию соберет всю информацию календаря (update), проиндексирует её (hash) и свяжет между собой таблицы (bind). Если что-то пойдет не так на любом из этапов, признаком ошибки станет 0 в переменной t. В случае успеха там останется значение из функции TimeTradeServer (напомним, оно ставится внутри update). Такой готовый к работе объект можно экспортировать в файл методом save, описанным выше.

При запуске в тестере объект следует создавать с особым сочетанием параметров from и to (from > to), чтобы программа посчитала строку context именем файла и загрузила из него состояние календаря. Проще всего это сделать так:

CalendarCache calca("filename.cal", true);

Внутри метода load мы также вызовем hash и bind, чтобы привести объект в рабочее состояние.

   bool load(const string filename)
   {
      ... // чтение файла было показано ранее
      const bool result = hash() && bind();
      if(!result) t = 0;
      return result;
   }

На примере функции CalendarValueLast покажем эквивалентную реализацию метода calendarValueLast (с точно таким же прототипом). В качестве идентификатора изменений кэш будет использовать текущее "серверное" время, за неимением открытого программного API для чтения таблицы изменений онлайн-календаря. Гипотетически мы могли бы воспользоваться информацией об идентификаторах изменений, сохраненных сервисом CalendarChangeSaver.mq5, но этот подход требует долговременного сбора статистики, прежде чем можно начать тестирование. Поэтому "серверное" время, генерируемое тестером, принято достаточно адекватной заменой.

Когда MQL-программа запросит изменения первый раз с нулевым идентификатором, просто вернем значение из TimeTradeServer.

   int calendarValueLast(ulong &change, MqlCalendarValue &result[],
      const string code = NULL, const string currency = NULL)
   {
      if(!change)
      {
         change = TimeTradeServer();
         return 0;
      }
      ...

Если идентификатор изменений уже ненулевой, продолжаем основную ветвь алгоритма.

В зависимости от содержимого параметров code и currency, находим идентификаторы страны и валюты. По умолчанию она равны 0, что означает поиск всех изменений.

      ulong country_id = 0;
      ulong currency_id = currency != NULL ? currencyId(currency) : 0;

      if(code != NULL)
      {
         for(int i = 0; i < ArraySize(countries); ++i)
         {
            if(countries[i].code == code)
            {
               country_id = countries[i].id;
               break;
            }
         }
      }
      ...

Далее, используя переданный отсчет времени change как начало поиска, находим все новости в value2time вплоть до нового, текущего значения TimeTradeServer. Внутри цикла с помощью метода find находим индекс соответствующей структуры MqlCalendarValue в массиве values и при необходимости сравниваем страну и валюту связанного вида события с желаемыми. Все новости, удовлетворяющие критериям, записываются в выходной массив result.

      const ulong past = change;
      const int index = ArrayBsearch(value2time, past);
      if(index < 0 || index >= ArrayRange(value2time, 0)) return 0;

      int i = index;
      while(value2time[i][0] <= (ulong)past && i < ArrayRange(value2time, 0)) ++i;

      if(i >= ArrayRange(value2time, 0)) return 0;

      for(int j = i; j < ArrayRange(value2time, 0)
         && value2time[j][0] <= (ulong)TimeTradeServer(); ++j)
      {
         const int p = find(value2time[j][1], id4value, values);
         if(p != -1)
         {
            change = TimeTradeServer();
            if(country_id != 0 || currency_id != 0)
            {
               const int q = find(values[p].event_id, id4event, events);
               if(country_id != 0 && country_id != events[q].country_id) continue;
               if(currency_id != 0)
               {
                  const int m = find(events[q].country_id, id4country, countries);
                  if(countries[m].currency != currency) continue;
               }
            }

            PUSH(result, values[p]);
         }
      }

      return ArraySize(result);
   }

По похожему принципу реализованы методы calendarValueHistory, calendarValueHistoryByEvent, calendarValueLastByEvent (последний фактически делегирует всю работу рассмотренному методу calendarValueLast). С полным исходным кодом можно ознакомиться в прилагаемом файле CalendarCache.mqh.

На основе класса кэша логично создать класс-наследник CalendarFilter, который бы при обработке запросов обращался к кэшу, вместо календаря.

Готовое решение находится в файле CalendarFilterCached.mqh. Благодаря тому, что программный интерфейс кэша проектировался по кальке стандартного API, интеграция сводится лишь к пробрасыванию вызовов фильтра в объект-кэш (автоуказатель cache).

class CalendarFilterCached: public CalendarFilter
{
protected:
   AutoPtr<CalendarCache> cache;

   virtual bool calendarCountryById(ulong country_id, MqlCalendarCountry &cnt) override
   {
      return cache[].calendarCountryById(country_id, cnt);
   }

   virtual bool calendarEventById(ulong event_id, MqlCalendarEvent &event) override
   {
      return cache[].calendarEventById(event_id, event);
   }

   virtual int calendarValueHistoryByEvent(ulong event_id, MqlCalendarValue &temp[],
      datetime _from, datetime _to = 0) override
   {
      return cache[].calendarValueHistoryByEvent(event_id, temp, _from, _to);
   }

   virtual int calendarValueHistory(MqlCalendarValue &temp[],
      datetime _from, datetime _to = 0,
      const string _code = NULL, const string _coin = NULL) override
   {
      return cache[].calendarValueHistory(temp, _from, _to, _code, _coin);
   }

   virtual int calendarValueLast(ulong &_change, MqlCalendarValue &result[],
      const string _code = NULL, const string _coin = NULL) override
   {
      return cache[].calendarValueLast(_change, result, _code, _coin);
   }

   virtual int calendarValueLastByEvent(ulong event_id, ulong &_change,
      MqlCalendarValue &result[]) override
   {
      return cache[].calendarValueLastByEvent(event_id, _change, result);
   }

public:
   CalendarFilterCached(CalendarCache *_cache): cache(_cache),
      CalendarFilter(_cache.getContext(), _cache.getFrom(), _cache.getTo())
   {
   }

   virtual bool isLoaded() const override
   {
      // готовность определяется кэшем
      return cache[].isLoaded();
   }
};

Для проверки работы календаря в тестере создадим новую версию индикатора CalendarMonitor.mq5 — CalendarMonitorCached.mq5.

Основные отличия заключаются в следующем.

Предполагаем, что некоторый файл кэша будет создан или уже создан под именем "xyz.cal" (в папке MQL5/Files) и потому подключаем его к MQL-программе директивой tester_file.

#property tester_file "xyz.cal"

Напомним, эта директива обеспечивает передачу кэша на любые агенты, включая распределенные (что, впрочем, более актуально для экспертов, а не индикатора). Создать файл кэша с этим (или другим именем) позволяет новая входная переменная CalendarCacheFile. Если пользователь изменит имя по умолчанию на что-то другое, то для работы в тестере нужно будет подправить директиву (требует перекомпиляции!), или перенести файл в общую папку терминалов (эта возможность поддержана в классе кэша, но "оставлена за кадром"), правда такой файл уже недоступен для удаленных агентов.

input string CalendarCacheFile = "xyz.cal";

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

AutoPtr<CalendarFilter> fptr;
AutoPtr<CalendarCache> cache;

В начале OnInit появился новый фрагмент, отвечающий за генерацию кэша и его чтение.

int OnInit()
{
   cache = new CalendarCache(CalendarCacheFile, true);
   if(cache[].isLoaded())
   {
      fptr = new CalendarFilterCached(cache[]);
   }
   else
   {
      if(MQLInfoInteger(MQL_TESTER))
      {
         Print("Can't run in the tester without calendar cache file");
         return INIT_FAILED;
      }
      else
      if(StringLen(CalendarCacheFile))
      {
         Alert("Calendar cache not found, trying to create '" + CalendarCacheFile + "'");
         cache = new CalendarCache();
         if(cache[].save(CalendarCacheFile))
         {
            Alert("File saved. Re-run indicator in online chart or in the tester");
         }
         else
         {
            Alert("Error: ", _LastError);
         }
         ChartIndicatorDelete(0, 0, MQLInfoString(MQL_PROGRAM_NAME));
         return INIT_PARAMETERS_INCORRECT;
      }
      Alert("Currently working in online mode (no cache)");
      fptr = new CalendarFilter(Context);
   }
   CalendarFilter *f = fptr[];
   ... // далее без изменений

Если файл кэша удалось прочитать, мы получим готовый объект CalendarCache, который передается в конструктор CalendarFilterCached. В противном случае программа проверяет, выполняется ли она в тестере или онлайн. Отсутствие кэша в тестере — это фатальный случай. На обычном же графике программа создает новый объект на основе данных встроенного календаря и сохраняет его в кэш под указанным именем. Если же имя файла сделать пустым, индикатор будет работать в точности, как исходный — напрямую с календарем.

Запустим индикатор на графике EURUSD. Пользователю будет выведено предупреждение о том, что указанный файл не найден и сделана попытка его сохранить. При условии, что календарь включен в настройках терминала, мы должны получить примерно следующие строки в журнале. Здесь приводится вариант с подробной диагностической информацией — её можно отключить, закомментировав в исходном коде директиву #define LOGGING.

Loading calendar cache xyz.cal
FileOpen(filename,FILE_READ|FILE_BIN|flags)=-1 / CANNOT_OPEN_FILE(5004)
Alert: Calendar cache not found, trying to create 'xyz.cal'
Reading online calendar base...
CalendarValueHistory(values,from,to,country,currency)=157173 / ok
CalendarEventByCountry(country,events)=1493 / ok
CalendarCountries(countries)=23 / ok
Hashing calendar...
ArraySize(countries)=23 / ok
ArrayResize(id4country,size2prime(c))=53 / ok
Total collisions: 9, worse:3, average: 2.25 in 4
ArraySize(events)=1493 / ok
ArrayResize(id4event,size2prime(e))=3079 / ok
Total collisions: 495, worse:7, average: 1.43478 in 345
ArraySize(values)=157173 / ok
ArrayResize(id4value,size2prime(v))=393241 / ok
Total collisions: 3511, worse:1, average: 1.0 in 3511
Binding calendar tables...
FileOpen(filename,FILE_WRITE|FILE_BIN|flags)=1 / ok
Alert: File saved. Re-run indicator in online chart or in the tester

Теперь мы можем выбрать индикатор CalendarMonitorCached.mq5 в тестере и увидеть в динамике, на истории, как меняется таблица новостей.

Новостной индикатор с кэшем календаря в тестере

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

Фильтрация событий по множеству условий

Торговля по календарю