Библиотеки: Calendar

Новый комментарий
 

Calendar:

Календарь - фундаментальный анализ на истории и в реал-тайме.

Author: fxsaber

 
Маэстро взялся за фундамент. Браво! Грядут великие перемены :)
 
Aleksey Mavrin:
Маэстро взялся за фундамент. Браво! Грядут великие перемены :)

Пока ничто не грядёт. Библиотеки. 

 
При первоначальной публикации в исходный код случайно попал мусор. Обновил код.
 
Для себя использую, как напоминалку. 
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/ru/code/32430

int OnInit()
{
  return(!EventSetTimer(1));
}

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Получили валюты текущего символа.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Взяли предстоящие важные события по валютам символа.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Распечатали их.
}

Вероятность пропустить важную новость значительно уменьшается.


Такой топорный вызов с нуля выполняется в течение 0.6 мс. Конечно, можно свести к нулевому потреблению.

 

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

Для MT4 так и делаю.

 
ИМХО, все же не хватает более подробной документации. Понятно, что можно заглянуть в код, но тогда вместо разбирания в чужом коде можно и свой написать ;-). В частности, не понятно, можно ли вызывать Get, не сделав предварительно Set, и можно ли откатить фильтр (насколько я понял, нельзя). Из приведенных примеров не ясно, есть ли более удобный способ отслеживания наступившего события - в частности, если я правильно понял, то нужно сравнивать change_id, а не наступление TimeCurrent, потому что обновление данных не обязательно точно совпадает с началом события.
 

Stanislav Korotky:
ИМХО, все же не хватает более подробной документации. Понятно, что можно заглянуть в код, но тогда вместо разбирания в чужом коде можно и свой написать ;-).

Внутри mqh нажать ALT+M. Из названий методов, вроде, понятен смысл.

В частности, не понятно, можно ли вызывать Get, не сделав предварительно Set, и можно ли откатить фильтр (насколько я понял, нельзя).

Set - наполняет объект событиями. Доступ к которым, как к элементам массива.

Из приведенных примеров не ясно, есть ли более удобный способ отслеживания наступившего события - в частности, если я правильно понял, то нужно сравнивать change_id, а не наступление TimeCurrent, потому что обновление данных не обязательно точно совпадает с началом события.

Если говорить про бэктест, то там нет и быть не может change_id.

Что касается реал-тайм, то данный функционал будет добавлен немного позже в библиотеку.


ЗЫ Откат фильтра, как и везде: делаем копию объекта до фильтра.

 

Архитектурно сделано так, чтобы можно было встраивать другие источники данных в виде парсеров. Для этого даже есть поле EVENT::Source, которое сейчас равно только одному значению "MetaTrader5".

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

 
fxsaber:

Если говорить про бэктест, то там нет и быть не может change_id.

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

 
Stanislav Korotky:

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

Календарь содержит четыре значения для каждого события:

  • Текущее (Actual) - первое значение, полученное после выхода новости.
  • Прогнозное (Forecast) - какое значение прогнозировалось (кем?) до выхода новости.
  • Предыдущее (Previous) - какое значение было получено первым после выхода этой же календарной новости в предыдущий раз. Т.е. оно равно Actual для предыдущего раза: Previous[i] =  Actual[i - 1].
  • Пересмотренное (Revised) - скорректированное значение предыдущего Actual. Время (и количество раз) этого обновления не сохраняется в календаре.

Во всех HTML-календарях (включая штатный и в Терминале) тройка (Actual, Forecast, Previous) = (Actual, Forecast, Revised). Поэтому на истории нельзя использовать Revised-поле до наступления следующего соответствующего события. Остальные - можно.

Нет (и быть не может ) информации о величине лага получения Actual, а точнее о рассинхроне конкретного торгового сервера и первоисточника новости. Поэтому в бэктесте это не учитывается. Этот нюанс понятен.


С учетом вышесказанного в бэктесте полностью правомочно сравнение TimeTradeServer со временем события. И использование значений  (Previous, Forecast, Revised) прямо перед событием, (Actual, Forecast, Previous) - сразу после.

1234567891011
Новый комментарий
Причина обращения: