Теория категорий в MQL5 (Часть 13): События календаря со схемами баз данных

Введение

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

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

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

Необходимость эффективной классификации событий календаря

События календаря создаются почти ежедневно, причем большинство из них анонсируются заранее - на несколько месяцев вперед. События публикуются в экономическом календаре MetaTrader и отображают валютные и макроэкономические показатели Китая, США, Японии, Германии, ЕС, Великобритании, Южной Кореи, Сингапура, Швейцарии, Канады, Новой Зеландии, Австралии и Бразилии. Список динамический, поэтому в будущем в него могут быть добавлены новые страны. Эти показатели часто (но не всегда) имеют числовые значения, которые в основном содержат прогнозируемое значение, фактическое значение и предыдущее значение. Формат числовых показателей сильно различается от одного показателя к другому. Многие показатели по своей сути несравнимы друг с другом, и это в каком-то смысле представляет нашу постановку проблемы.

Чтобы использовать показания индикаторов для этих валют и экономик, трейдерам необходимо надежно и последовательно считывать числовые значения и/или точно интерпретировать опубликованный текст. Давайте рассмотрим несколько типичных календарных событий.

Выше представлены четыре события для Китая, США, Японии и Германии, которые отражают индекс, процентную доходность, денежные суммы и неопределенное значение соответственно. Эту информацию можно получить в MQL5 простыми методами, как показано ниже.

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void SampleRetrieval(string Currency)
   {
      MqlCalendarValue _value[];
      datetime _stop_date=datetime(__start_date+int(PeriodSeconds(__stop_date_increment)));
//--- get events
      MqlCalendarEvent _event[];
      int _events=CalendarEventByCurrency(Currency,_event);
      printf(__FUNCSIG__+" for Currency: "+Currency+" events are: "+IntegerToString(_events));
      //
      for(int e=0;e<_events;e++)
      {
         int _values=CalendarValueHistoryByEvent(_event[e].id, _value, __start_date, _stop_date);
         //
         for(int v=0;v<_values;v++)
         {
            //
            printf(__FUNCSIG__+" Calendar Event code: "+_event[e].event_code+", for value: "+TimeToString(_value[v].period)+" on: "+TimeToString(_value[v].time)+", has... ");
            //
            if(_value[v].HasPreviousValue())
            {
               printf(__FUNCSIG__+" Previous value: "+DoubleToString(_value[v].GetPreviousValue()));
            }
            
            if(_value[v].HasForecastValue())
            {
               printf(__FUNCSIG__+" Forecast value: "+DoubleToString(_value[v].GetForecastValue()));
            }
            
            if(_value[v].HasActualValue())
            {
               printf(__FUNCSIG__+" Actual value: "+DoubleToString(_value[v].GetActualValue()));
            }
         }
      }
   }

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

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

Особо следует упомянуть текстовое описание самого события, которое, как предполагается, является способом, которым трейдер идентифицирует событие. Например, при анализе пары EURUSD, в идеале вам необходимо учитывать события EUR и сопоставимые события USD. Но как работать, например, с такими событиями:

Со своими, казалось бы, сопоставимыми аналогами на стороне USD:

А также:

Работая с EUR, мы учитываем настроения евро или настроения Германии? Или мы должны использовать оба со взвешиванием? И если да, то какие веса использовать? Что касается USD, какие значения Мичигана или Филадельфии мы должны использовать?

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

Существующие методы классификации слишком просты. Они включают в себя: выбор событий по идентификатору, выбор событий по стране и выбор событий по валюте. Есть несколько других категорий, учитывающих ценность этих событий, но они не сильно отличаются от этих классификаций. Кроме того, выбор по стране и валюте создает двусмысленность, во многом из-за EUR. Отсутствуют базовые аспекты, позволяющие определить, является ли событие ретроспективным, как индекс, или смотрящим в будущее, как рыночное настроение. Кроме того, необходимость сравнения разных валют для одного и того же события в некоторых случаях не так четко определена, как показано выше для пары EURUSD.

Концепции теории категорий и схемы баз данных

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

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

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

При таком базовом макете таблица событий будет иметь столбец даты и кода в качестве первичного ключа. Столбец кода содержит данные кода события, считанные из событий календаря. Таблицы Currencies (валюты), Countries (страны) и Events (события) могут иметь свои первичные ключи в виде столбцов currency_id, countries_id и event_id соответственно. Однако таблица значений валютных пар должна будет объединить столбцы date и event_id для своего первичного ключа.

Вышеупомянутое не является схемой, поскольку связи между таблицами не указаны. Это просто таблицы в нашей базе данных. Часть схемы показана ниже.

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

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

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

Реализация средствами MQL5

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

//+------------------------------------------------------------------+
//| Square Commute Class to illustrate Universal Property            |
//+------------------------------------------------------------------+
template <typename TA,typename TB,typename TC,typename TD>
class CCommuteSquare
   {
      public:
      
      CHomomorphism<TA,TB>          ab;
      CHomomorphism<TA,TC>          ac;
      CHomomorphism<TD,TB>          db;
      CHomomorphism<TD,TC>          dc;
      
      CHomomorphism<TD,TA>          da;   //universal property
      
      virtual void                  SquareAssert()
                                    {
                                       ab.domain=ac.domain;
                                       ab.codomain=db.codomain;
                                       dc.domain=db.domain;
                                       dc.codomain=ac.codomain;
                                       
                                       da.domain=db.domain;
                                       da.codomain=ac.domain;
                                    }
      
                                    CCommuteSquare(){};
                                    ~CCommuteSquare(){};
   };

То, что мы добавили к оригиналу, — это просто дополнительный гомоморфизм универсального свойства. Итак, после этого следующим ключевым моментом будет определение элементов для каждого множества, которое собирает соответствующие данные. Это можно сделать для множества событий (показанного в виде таблицы событий), как указано ниже:

//sample constructor for event set
CElement<string> _e_event;_e_event.Cardinality(7);
//

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

//sample constructor for type set
CDomain<string> _d_type;_d_type.Cardinality(_types);
//data population
CElement<string> _e_type;_e_type.Cardinality(1);

      //sample constructor for currency set
CDomain<string> _d_currency;_d_currency.Cardinality(_currencies);
//data population
CElement<string> _e_currency;_e_currency.Cardinality(1);

Это приводит к элементам значения валютной пары. Это множество объединяет валюты в общую торгуемую пару, которая имеет ценовой график при выборе из "Обзора рынка" с добавлением нового числового значения, которое является эффективным значением пары, полученным в результате объединения двух значений событий каждой валюты. Так, например, если у нас есть значения розничных продаж для зоны евро, которые будут сопоставлены с EUR, и розничные продажи для США, которые сопоставлены с USD, то во множестве значений валютной пары будет указана пара EURUSD с ее эффективным значением розничных продаж. Ниже показан листинг для создания его элемента:

//sample constructor for values set
CDomain<string> _d_values;_d_values.Cardinality(_values);
//data population
CElement<string> _e_values;_e_values.Cardinality(4);

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

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

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

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class CDatabase
  {
      public:
      
      STableEvents               events;
      STableEventTypes           event_types;
      STableCountries            countries;
      STableCurrencies           currncies;
      
      
                                 CDatabase(void);
                                 ~CDatabase(void);
  };

Отличие этого подхода от SQL заключается в том, что данные сохраняются в оперативной памяти, которая является временной, тогда как SQL, как правило, хранит данные на жестком диске. Однако этот класс позволяет нам экспортировать его в существующую базу данных, и поскольку в MQL5 IDE есть некоторые возможности работы с базой данных, вы можете в конечном итоге прочитать эти значения из физической базы данных, а не из оперативной памяти, чтобы сэкономить вычислительные ресурсы.

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

Когда у нас есть множества, мы переходим к самому интересному — определению гомоморфизмов между этими множествами. Гомоморфизм набора событий к набору типов событий будет просто сопоставлять события с их типом, что с точки зрения проектирования базы данных означает, что мы можем иметь только столбец индекса типов в таблице событий, а фактические типы с их индексами будут в таблице типов событий. Отношение внешнего ключа (foreign key) между ними было бы эквивалентно нашему гомоморфизму. Поскольку это не база данных, во множестве типов у нас есть все типы, уже перечисленные как часть набора событий, но без повторений, что означает, что наше множество событий — это домен, а типы событий — это кодомен. Таким образом, гомоморфизм можно легко определить, используя следующий листинг:

      //ab homomorphisms
      CHomomorphism<string,string> _ab;
      
      CElement<string> _e;
      for(int s=0;s<_sc.ab.domain.Cardinality();s++)
      {
         _e.Let();
         if(_sc.ab.domain.Get(s,_e))
         {
            string _s="";
            if(_e.Get(0,_s))
            {
               CMorphism<string,string> _m;
               _m.Morph(_sc.ab.domain,_sc.ab.codomain,s,EventType(_s));
               
               _ab.Morphisms(_ab.Morphisms()+1);
               _ab.Set(_ab.Morphisms()-1,_m);
            }
         }
      }

Аналогично, гомоморфизм событий и валют представляет собой прямое сопоставление, которое можно реализовать с помощью приведенного ниже листинга:

      //ac homomorphisms
      CHomomorphism<string,string> _ac;
      
      for(int s=0;s<_sc.ac.domain.Cardinality();s++)
      {
         _e.Let();
         if(_sc.ac.domain.Get(s,_e))
         {
            string _s="";
            if(_e.Get(1,_s))
            {
               CMorphism<string,string> _m;
               int _c=EventCurrency(_s);
               if(_c!=-1)
               {
                  _m.Morph(_sc.ac.domain,_sc.ac.codomain,s,_c);
                  
                  _ac.Morphisms(_ac.Morphisms()+1);
                  _ac.Set(_ac.Morphisms()-1,_m);
               }
            }
         }
      }

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

      //db homomorphisms
      CHomomorphism<string,string> _db;
      
      for(int s=0;s<_values;s++)
      {
         _e.Let();
         if(_sc.db.domain.Get(s,_e))
         {
            string _s="";
            if(_e.Get(3,_s))
            {
               int _t=TypeToInt(_s);
               CMorphism<string,string> _m;
               //
               _m.Morph(_sc.db.domain,_sc.db.codomain,s,_t);
               
               _db.Morphisms(_db.Morphisms()+1);
               _db.Set(_db.Morphisms()-1,_m);
            }
         }
      }

Аналогично, сопоставление валют может выглядеть следующим образом:

      //dc homomorphisms
      CHomomorphism<string,string> _dc;
      
      for(int s=0;s<_values;s++)
      {
         _e.Let();
         if(_sc.dc.domain.Get(s,_e))
         {
            string _s="";
            if(_e.Get(0,_s))//morphisms for margin currency only
            {
               int _c=EventCurrency(_s);
               
               CMorphism<string,string> _m;
               //
               _m.Morph(_sc.dc.domain,_sc.dc.codomain,s,_c);
               
               _dc.Morphisms(_dc.Morphisms()+1);
               _dc.Set(_dc.Morphisms()-1,_m);
            }
         }
      }

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

      //da homomorphisms
      CHomomorphism<string,string> _da;
      
      for(int s=0;s<_values;s++)
      {
         _e.Let();
         if(_sc.da.domain.Get(s,_e))
         {
            string _s_c="",_s_t="";
            if(_e.Get(0,_s_c) && _e.Get(3,_s_t))// for margin currency
            {
               for(int ss=0;ss<_sc.ac.domain.Cardinality();ss++)
               {
                  CElement<string> _ee;
                  if(_sc.da.codomain.Get(ss,_ee))
                  {
                     string _ss_c="",_ss_t="";
                     if(_ee.Get(1,_ss_c) && _ee.Get(6,_ss_t))// for margin currency
                     {
                        if(_ss_c==_s_c && _ss_t==_s_t)
                        {
                           CMorphism<string,string> _m;
                           //
                           _m.Morph(_sc.da.domain,_sc.da.codomain,s,ss);
                           
                           _da.Morphisms(_da.Morphisms()+1);
                           _da.Set(_da.Morphisms()-1,_m);
                           
                           _sc.da=_da; _sc.SquareAssert();
                           
                           break;
                        }
                     }
                  }
               }
            }
         }
      }
      
      _da.domain=_sc.da.domain;
      _da.codomain=_sc.da.codomain;
      _sc.da=_da; _sc.SquareAssert();

Таким образом, это станет последним шагом в определении эффективных весов валютной пары на основе календарных событий отдельных валют.

Классификация событий календаря

При составлении таблицы типов событий может быть разумным следовать строгой методологии, которая учитывает критическую массу данных, прежде чем переходить к типам событий. Классификация событий важна, как было указано в постановке задачи, поэтому возможная методология классификации этих событий по сопоставимым типам может включать: сбор данных - базовое извлечение данных с использованием встроенных классов MQL5 было описано выше. Затем последует группировка событий, где мы сможем использовать стандартные группы, такие как индексы, показатели настроений, доходность казначейских облигаций, показатели инфляции и т. д. За этим последует извлечение признаков, поскольку каждое событие будет анализироваться на предмет ключевых слов, чтобы определить, к какой группе оно принадлежит. Далее последует обучение модели и оценка нашей классификации объектов, где мы создадим наборы данных для обучения и тестирования и начнем с обучения модели. Последует тестирование модели на тестовом наборе данных, чтобы увидеть, насколько хорошо она классифицирует наши события. И наконец пост-анализ и итеративное улучшение завершат процесс, рассматривая способы точной настройки нашей модели без чрезмерной подгонки.

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

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

Информирование о торговых решениях

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

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

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

Пример: внедрение и оценка в MQL5

Для краткости это будет не полная торговая система, а только начальные ее части, которые учитывают нашу композицию, состоящую из четырех множеств: события, тип, валюты и значения. Мы получим данные о событиях календаря напрямую, а не с помощью нашего класса базы данных, заполним экземпляр класса квадратного перемещения и считаем, какие гомоморфизмы мы можем сгенерировать. Опять же, это только начальный шаг, который предназначен исключительно для демонстрации потенциала. С этой целью наши входные данные включают: тип события, на котором мы сосредоточимся, вес для валюты покупки (bid)/маржи и вес для валюты продажи (ask)/прибыли. Как уже говорилось, эти веса предназначены для объединения календарных значений двух валют в одну. Для этого исследования мы учитываем только события, связанные с PMI (индекс деловой активности), и рассматриваем только валюты EUR, GBP, USD, CHF и JPY, а также значения только для пар EURUSD, GBPUSD, USDCHF и USDJPY. Весь код приложен в конце статьи. При распечатке гомоморфизма универсальных свойств, мы должны получить следующие записи:

2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) void OnStart() d to a homomorphisms are... 
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) 
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) {(EUR,USD,45.85000000,TYPE_PMI),(GBP,USD,47.00000000,TYPE_PMI),(USD,CHF,45.05000000,TYPE_PMI),(USD,JPY,48.75000000,TYPE_PMI)}
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) |
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) (EUR,USD,45.85000000,TYPE_PMI)|----->(markit-manufacturing-pmi,EUR,44.60000000,44.60000000,44.80000000,2023.06.01 11:00,TYPE_PMI)
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) |
2023.07.11 13:51:52.966 ct_13 (GBPUSD.i,H1) {(markit-manufacturing-pmi,EUR,44.60000000,44.60000000,44.80000000,2023.06.01 11:00,TYPE_PMI),(markit-manufacturing-pmi,EUR,44.80000000,44.20000000,43.60000000,2023.06.23 11:00,TYPE_PMI),(markit-services-pmi,EUR,55.90000000,55.90000000,55.10000000,2023.06.05 11:00,TYPE_PMI),(markit-services-pmi,EUR,55.10000000,55.50000000,52.40000000,2023.06.23 11:00,TYPE_PMI),(markit-composite-pmi,EUR,53.30000000,53.30000000,52.80000000,2023.06.05 11:00,TYPE_PMI),(markit-composite-pmi,EUR,52.80000000,53.00000000,50.300000

Используя только данные PMI и предварительно выбранные выше валюты и пары, мы получаем только один морфизм для маржинальной валюты, которой в данном случае является EUR. Наше совокупное значение было выше, чем входное значение EUR просто потому, что эквивалентное значение PMI для доллара США было выше, а напечатанное значение для пары EURUSD было просто средневзвешенным значением. В этом конкретном тесте использовались равные веса как для EUR, так и для USD.

Заключение

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

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