Libraries: Calendar

[Automated-Trading]

Calendar:

Calendar - fundamental analysis on history and real-time.

Author: fxsaber

[Aleksey Mavrin]

The maestro has taken on the foundation. Bravo! Great changes are coming :)

[Алексей Тарабанов]

Aleksey Mavrin:
The maestro has taken on the foundation. Bravo! Great changes are coming :)

Nothing is coming yet. Libraries.

[fxsaber]

During initial publication, the source code accidentally got rubbish in it. Updated the code.

[fxsaber]

For myself, I use it as a reminder.

#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/ru/code/32430

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

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Get the currencies of the current character.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Took upcoming important events by symbol currencies.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Printed them out.
}

The likelihood of missing important news is greatly reduced.

Such a hatchet call from zero is executed within 0.6 ms. Of course, it is possible to reduce to zero consumption.

[fxsaber]

Thecalendar of events is written much further into the future. Therefore, you can also use a reminder in MT4 by saving a file from MT5 data (a month in advance, for example).

This is what I do for MT4.

[Stanislav Korotky]

IMHO, more detailed documentation is still missing. It is clear that you can look into the code, but then you can write your own code instead of analysing other people's code ;-). In particular, it's not clear whether you can call Get without first doing Set, and whether you can roll back the filter (as far as I understand, you can't). It is not clear from the above examples whether there is a more convenient way to track the occurrence of the event - in particular, if I understood correctly, we should compare change_id, not the occurrence of TimeCurrent, because the data update does not necessarily coincide exactly with the beginning of the event.

[fxsaber]

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

Inside mqh press ALT+M. The names of the methods seem to make sense.

In particular, it's not clear whether Get can be called without first doing Set, and whether you can roll back the filter (as far as I understand, you can't).

Set - fills the object with events. Access to which is like accessing elements of an array.

From the above examples it is not clear if there is a more convenient way to track the occurrence of the event - in particular, if I understood correctly, you need to compare change_id, not the occurrence of TimeCurrent, because the data update does not necessarily coincide exactly with the beginning of the event.

If we're talking about backtest, there is not and cannot be a change_id.

As for real-time, this functionality will be added a bit later in the library.

The filter rollback is the same as everywhere else: make a copy of the object before the filter.

[fxsaber]

Architecturally it is made so that it is possible to embed other data sources in the form of parsers. There is even an EVENT::Source field for this purpose, which is now equal to only one value "MetaTrader5".

So there is functionality to stack calendars. Assumed that it took data from several sources and then combined them in one place.

[Stanislav Korotky]

fxsaber:

If we are talking about backtest, there is no change_id there and there can't be.

This is a questionable nuance: in real life events can change, and if the tester (via the library) does not reproduce the history of changes, the adequacy of testing falls. A similar topic has already been touched upon here in some threads: online indicators in an event are the same, and then they are corrected. If we test using the corrected values, we will not get the picture that the expert analysed "on the fly". Well, or I misunderstood the situation with access to updates.

[fxsaber]

Stanislav Korotky:

This is a questionable nuance: in real life events can change, and if the tester (via the library) does not reproduce the history of changes, the adequacy of testing drops. A similar topic has already been touched upon here in some threads: online indicators in an event are the same, and then they are corrected. If we test using the corrected values, we will not get the picture that the expert analysed "on the fly". Well, or I misunderstood the situation with access to updates.

The calendar contains four values for each event:

• Current (Actual) - the first value received after the news release.
• Forecast - what value was predicted (by whom?) before the news was released.
• Previous - what value was received first after the same calendar news was released the previous time. I.e. it is equal to Actual for the previous time: Previous[i] = Actual[i - 1].
• Revised - the adjusted value of the previous Actual. The time (and number of times) of this update is not stored in the calendar.

In all HTML calendars (including the standard one and in Terminal) the triple (Actual, Forecast, Previous) = (Actual, Forecast, Revised). Therefore, you cannot use the Revised field on history until the next relevant event occurs. The others can be used.

There is no (and cannot be ) information about the lag value of receiving Actual, or, more precisely, about the disynchronisation of a particular trading server and the news source. That is why it is not taken into account in the backtest. This nuance is clear.

Taking into account the above, it is completely legitimate to compare TimeTradeServer with the time of the event in the backtest. And using values (Previous, Forecast,Revised) right before the event, (Actual, Forecast,Previous) - right after.