Librerías: Calendario

Nuevo comentario
 

Calendario:

Calendario: análisis fundamental histórico y en tiempo real.

Calendario

Author: fxsaber

 
El maestro ha asumido la fundación. ¡Bravo! Se avecinan grandes cambios :)
 
Aleksey Mavrin:
El maestro ha asumido la fundación. ¡Bravo! Se avecinan grandes cambios :)

Todavía no viene nada. Bibliotecas.

 
Durante la publicación inicial, el código fuente contenía accidentalmente basura. Se ha actualizado el código.
 
A mí me sirve de recordatorio. 
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/es/code/32430

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

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Obtener las monedas del carácter actual.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Tomó los próximos eventos importantes por símbolo monedas.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Los imprimí.
}

La probabilidad de perderse noticias importantes se reduce considerablemente.


Una llamada de este tipo desde cero se ejecuta en 0,6 ms. Por supuesto, es posible reducir a cero el consumo.

 

Elcalendario de eventos se escribe con mucha más antelación. Por lo tanto, también puede utilizar un recordatorio en MT4 guardando un archivo de datos de MT5 (con un mes de antelación, por ejemplo).

Esto es lo que yo hago para MT4.

 
En mi opinión, sigue faltando una documentación más detallada. Está claro que puedes mirar en el código, pero entonces puedes escribir tu propio código en lugar de analizar el código de otras personas ;-). En particular, no está claro si se puede llamar a Get sin hacer primero Set, y si se puede deshacer el filtro (por lo que tengo entendido, no se puede). No queda claro en los ejemplos anteriores si hay una forma más conveniente de rastrear la ocurrencia del evento - en particular, si entendí bien, deberíamos comparar change_id, no la ocurrencia de TimeCurrent, porque la actualización de datos no necesariamente coincide exactamente con el inicio del evento.
 

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

Dentro de mqh pulsa ALT+M. Los nombres de los métodos parecen tener sentido.

En particular, no está claro si Get puede ser llamado sin hacer primero Set, y si se puede deshacer el filtro (por lo que entiendo, no se puede).

Set - llena el objeto con eventos. Su acceso es como el de los elementos de un array.

De los ejemplos anteriores no está claro si hay una manera más conveniente de rastrear la ocurrencia del evento - en particular, si he entendido bien, es necesario comparar change_id, no la ocurrencia de TimeCurrent, porque la actualización de datos no necesariamente coincide exactamente con el inicio del evento.

Si hablamos de backtest, no hay ni puede haber un change_id.

En cuanto al tiempo real, esta funcionalidad se añadirá un poco más adelante en la biblioteca.


La reversión del filtro es la misma que en todos los demás casos: hacer una copia del objeto antes del filtro.

 

Arquitectónicamente se ha hecho de forma que sea posible incrustar otras fuentes de datos en forma de analizadores sintácticos. Incluso hay un campo EVENT::Source para este propósito, que ahora es igual a un solo valor "MetaTrader5".

Así que hay funcionalidad para apilar calendarios. Se supone que tomó datos de varias fuentes y luego combinarlos en un solo lugar.

 
fxsaber:

Si hablamos de backtest, ahí no hay change_id ni puede haberlo.

Este es un matiz cuestionable: en la vida real los eventos pueden cambiar, y si el probador (a través de la biblioteca) no reproduce la historia de los cambios, la adecuación de las pruebas cae. Un tema similar ya se ha tocado aquí en algunos hilos: los indicadores en línea en un evento son los mismos, y luego se corrigen. Si hacemos las pruebas con los valores corregidos, no obtendremos la imagen que el experto analizó "sobre la marcha". Bueno, o he entendido mal la situación con el acceso a las actualizaciones.

 
Stanislav Korotky:

Este es un matiz cuestionable: en la vida real los eventos pueden cambiar, y si el probador (a través de la biblioteca) no reproduce el historial de cambios, la adecuación de las pruebas cae. Un tema similar ya se ha tocado aquí en algunos hilos: los indicadores en línea en un evento son los mismos, y luego se corrigen. Si hacemos pruebas utilizando los valores corregidos, no obtendremos la imagen que el experto analizó "sobre la marcha". Bueno, o he entendido mal la situación con el acceso a las actualizaciones.

El calendario contiene cuatro valores para cada evento:

  • Actual (Actual) - el primer valor recibido tras la publicación de la noticia.
  • Previsión: valor previsto (¿por quién?) antes de la publicación de la noticia.
  • Anterior: valor que se recibió en primer lugar tras la publicación de la misma noticia en el calendario anterior. Es decir, es igual a Actual para la vez anterior: Previous[i] = Actual[i - 1].
  • Revisado - el valor ajustado del Actual anterior. La hora (y el número de veces) de esta actualización no se almacena en el calendario.

En todos los calendarios HTML (incluido el estándar y en Terminal) la triple (Actual, Previsión, Anterior) = (Actual, Previsión, Revisado). Por lo tanto, no puede utilizar el campo Revisado en el historial hasta que se produzca el siguiente evento relevante. Los demás sí pueden utilizarse.

No hay (ni puede haber) información sobre el valor de desfase de la recepción de Actual o, más concretamente, sobre la desincronización de un servidor de negociación concreto y la fuente de noticias. Por eso no se tiene en cuenta en el backtest. Este matiz es evidente.


Teniendo en cuenta lo anterior, es completamente legítimo comparar TimeTradeServer con la hora del evento en el backtest. Y utilizando los valores (Anterior, Previsión,Revisado) justo antes del evento, (Actual, Previsión,Anterior) - justo después.

123456789101112131415
Nuevo comentario