Bibliotecas: Calendário

Novo comentário
 

Calendário:

Calendário - análise fundamental do histórico e em tempo real.

Calendário

Author: fxsaber

 
O maestro assumiu a fundação. Bravo! Grandes mudanças estão chegando :)
 
Aleksey Mavrin:
O maestro assumiu a fundação. Bravo! Grandes mudanças estão chegando :)

Nada está chegando ainda. Bibliotecas.

 
Durante a publicação inicial, o código-fonte foi acidentalmente contaminado. Atualizei o código.
 
Para mim, eu a uso como um lembrete. 
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/pt/code/32430

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

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Obter as moedas do caractere atual.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Anotou os próximos eventos importantes por moedas de símbolo.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Imprimiu-os.
}

A probabilidade de perder notícias importantes é bastante reduzida.


Essa chamada do zero é executada em 0,6 ms. É claro que é possível reduzir o consumo a zero.

 

Ocalendário de eventos é escrito muito mais para o futuro. Portanto, você também pode usar um lembrete no MT4 salvando um arquivo de dados do MT5 (com um mês de antecedência, por exemplo).

Isso é o que eu faço no MT4.

 
Na minha opinião, ainda falta uma documentação mais detalhada. Está claro que você pode examinar o código, mas então você pode escrever seu próprio código em vez de examinar o código de outras pessoas ;-). Em particular, não está claro se é possível chamar Get sem antes fazer Set e se é possível reverter o filtro (pelo que entendi, não é possível). Não está claro nos exemplos acima se há uma maneira mais conveniente de rastrear a ocorrência do evento - em particular, se eu entendi corretamente, devemos comparar change_id, não a ocorrência de TimeCurrent, porque a atualização de dados não necessariamente coincide exatamente com o início do evento.
 

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

Dentro do mqh, pressione ALT+M. Os nomes dos métodos parecem fazer sentido.

Em particular, não está claro se Get pode ser chamado sem antes fazer Set e se é possível reverter o filtro (pelo que entendi, não é possível).

Set - preenche o objeto com eventos. O acesso a eles é como o acesso a elementos de uma matriz.

A partir dos exemplos acima, não está claro se há uma maneira mais conveniente de rastrear a ocorrência do evento - em particular, se eu entendi corretamente, você precisa comparar change_id, não a ocorrência de TimeCurrent, porque a atualização de dados não necessariamente coincide exatamente com o início do evento.

Se estivermos falando de backtest, não há e não pode haver um change_id.

Quanto ao tempo real, essa funcionalidade será adicionada um pouco mais tarde na biblioteca.


A reversão do filtro é a mesma que em qualquer outro lugar: faça uma cópia do objeto antes do filtro.

 

Arquitetonicamente, ele foi criado para que seja possível incorporar outras fontes de dados na forma de analisadores. Há até mesmo um campo EVENT::Source para essa finalidade, que agora é igual a apenas um valor "MetaTrader5".

Portanto, existe a funcionalidade de empilhar calendários. Suponhamos que ele tenha obtido dados de várias fontes e depois os tenha combinado em um único local.

 
fxsaber:

Se estivermos falando de backtest, não há change_id lá e não pode haver.

Essa é uma nuance questionável: na vida real, os eventos podem mudar, e se o testador (por meio da biblioteca) não reproduzir o histórico de alterações, a adequação do teste cai. Um tópico semelhante já foi abordado aqui em alguns tópicos: os indicadores on-line em um evento são os mesmos e depois são corrigidos. Se testarmos usando os valores corrigidos, não obteremos a imagem que o especialista analisou "na hora". Bem, ou eu entendi mal a situação do acesso às atualizações.

 
Stanislav Korotky:

Essa é uma nuance questionável: na vida real, os eventos podem mudar, e se o testador (por meio da biblioteca) não reproduzir o histórico de alterações, a adequação do teste cai. Um tópico semelhante já foi abordado aqui em alguns tópicos: os indicadores on-line em um evento são os mesmos e depois são corrigidos. Se testarmos usando os valores corrigidos, não obteremos a imagem que o especialista analisou "na hora". Bem, ou eu entendi mal a situação do acesso às atualizações.

O calendário contém quatro valores para cada evento:

  • Atual (real) - o primeiro valor recebido após o comunicado à imprensa.
  • Previsão - qual valor foi previsto (por quem?) antes de a notícia ser divulgada.
  • Anterior - qual valor foi recebido primeiro depois que a mesma notícia do calendário foi divulgada na vez anterior. Ou seja, é igual ao Real para o momento anterior: Anterior[i] = Real[i - 1].
  • Revisado - o valor ajustado do Real anterior. A hora (e o número de vezes) dessa atualização não é armazenada no calendário.

Em todos os calendários HTML (incluindo o padrão e o do Terminal), a tripla (Real, Previsão, Anterior) = (Real, Previsão, Revisado). Portanto, não é possível usar o campo Revisado no histórico até que ocorra o próximo evento relevante. Os outros podem ser usados.

Não há (e não pode haver) informações sobre o valor de defasagem do recebimento do Real ou, mais precisamente, sobre a dessincronização de um servidor de negociação específico e a fonte de notícias. É por isso que isso não é levado em conta no backtest. Essa nuance é clara.


Levando em conta o que foi dito acima, é totalmente legítimo comparar o TimeTradeServer com a hora do evento no backtest. E usar valores (Anterior, Previsão,Revisado) logo antes do evento, (Real, Previsão,Anterior) - logo depois.

123456789101112131415
Novo comentário