Bug MQL5 quando se trabalha com acesso iClose/iOpen timeseries, etc. - página 9

[Unicornis]

Vitaly Muzichenko:

Então, será possível ter um indicador muito rápido com tal construção?

Mais provavelmente não, a OnCalculate não será chamada em cada carrapato, mas depois de um pacote de carrapatos.

Se assim for, esta é uma ótima notícia!

[fxsaber]

Renat Fatkhullin:

Temos uma idéia de indicadores, que não contêm a bandeira #property tester_everytick_calculate, para incluir o modo de cálculo baseado no recebimento de um pacote de carrapatos, em vez de em cada carrapato.

Isto resolverá radicalmente o problema dos indicadores tardios, preservando a possibilidade de processamento garantido de cada carrapato para alguns indicadores.

Eu proponho outra solução.

SymbolInfoTick

Retorna os preços atuais de um símbolo especificado em uma variável do tipo MqlTick.

bool  SymbolInfoTick( 
   string    symbol,     // символ 
   MqlTick&  tick        // ссылка на структуру
   bool      IndicatorMode = true; // индикаторный или реальный (текущий) тик
   );

Parâmetros

símbolo

[Nome simbólico.

carrapato .

[Uma referência de estrutura do tipoMqlTick, os preços atuais e o último tempo de atualização de preços são colocados nele.

IndicatorMode

[Verdadeiro - nos indicadores retorna o tique que acionou o atual NewCalculate, falso - tique atual (em tempo real) de um símbolo.

Valor retornado

Retorna verdadeiro se bem-sucedido, caso contrário, falso.

Então em OnCalculate será suficiente escrever apenas esta construção

// Возвращает true, если текущий и индикаторный тики совпадают
bool IsRealTick( void )
{
  MqlTick Tick1, Tick2;
  
  return(SymbolInfoTick(_Symbol, Tick1) && SymbolInfoTick(_Symbol, Tick2, false) && (Tick1.time_msc == Time2.time_msc));
}

int OnCalculate( ... )
{
  if (prev_calculated && !IsRealTick())
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  return(rates_total);
}

Esta solução seria mais flexível e conveniente de usar e implementar.

SZY Seria melhor ter a numeração de carrapatos, com possibilidade de obter o número de carrapatos de corrente e indicador. Mas esta variante é mais difícil para os desenvolvedores. Portanto, provavelmente, não é necessário.

[fxsaber]

fxsaber:

Sugiro outra solução.

Se nada for feito pelos desenvolvedores (o que, aliás, é uma opção muito boa), ainda é possível contornar todos os freios desta forma

int OnCalculate( ... )
{
  static ulong MinTimeMsc = 0
  const ulong StartTime = GetMicrosecondCount();
  
  MqlTick Tick;
  const bool Res = prev_calculated && SymbolInfoTick(_Symbol, Tick);
  
  if (Res && (Tick.timeMsc < MinTimeMsc))
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  if (Res)
    MinTimeMsc = Tick.time_msc + (GetMicrosecondCount - StartTime) / 2000;
  
  return(rates_total);
}

[Unicornis]

fxsaber:

Se os desenvolvedores não fizerem nada (o que, aliás, é uma opção muito boa), é possível contornar todos os freios agora desta forma

Bem, não precisamos de carrapatos no meio de um bar, eles são forçosamente pulados de qualquer maneira. Vamos esperar a implementação por mql.

[fxsaber]

Unicornis:

Bem, não precisamos de carrapatos no meio de um bar, eles são forçosamente pulados de qualquer maneira. Vamos esperar pela implementação do mql.

Honestamente, eu não entendo, o que impediu que os próprios doentes escrevessem uma solução para seu problema?

E por que os desenvolvedores deveriam mudar alguma coisa aqui?

A solução pode ser implementada como um arquivo mqh- e conectada a qualquer indicador, como é implementado no Init_Sync. Mas isso requer muito código que não é muito óbvio. E aqui são apenas algumas linhas.

[Farkhat Guzairov]

Renat Fatkhullin:

A atualização congelada do prazo invisível de outra pessoa após reconectar a comunicação foi resolvida e consertada. O motivo foi status de cache incorreto após a reconexão.

Versão Beta 1946 disponível via Help -> Check Desktop Updates -> Versão Beta mais recente.

Rinat, 3 dias de testes sem problemas, obrigado!

[Unicornis]

fxsaber:

Honestamente, eu não entendo o que impediu que os próprios doentes escrevessem uma solução para seu problema?

E por que os desenvolvedores deveriam mudar alguma coisa aqui?

Os que sofrem não podem alterar de forma alguma o número de ticks recebidos no indicador, eles os ignoram no indicador até uma nova barra, se o indicador contar por muito tempo, os ticks são ignorados de qualquer forma. De alguma forma, temos que nos ajustar à realidade.

Se para um símbolo o valor de pico for de ~800 ticks por minuto, então para sintéticos de vários símbolos já 2300 ticks por minuto. A abertura de um sintético e um símbolo a partir dele atinge um pico de ~3000 ticks por minuto. Acrescente outro cronograma do mesmo sintético e do mesmo símbolo, e nós obtemos... Ok, as telas do Elder eram três, recebemos ~9000 ticks por minuto ou 150 ticks por segundo. Rinat já escreveu sobre questões de desempenho. Por que passar 150 ticks por segundo através de um indicador multissimbolo-mtf quando você precisa de 1-n tick por minuto para todos os símbolos tf? Da mesma forma, os benefícios de hospedar mql não incluem nenhuma sobrecarga do sistema host, o terminal é o mesmo host apenas para indicadores e EAs. Se o cálculo do indicador consiste em RSI(3) + EMA(5) + EMA(7), é claro que não haverá problema nos próximos 10 anos.

No sintético (na verdade é um indicador multisímbolo do terminal) os desenvolvedores de alguma forma tiveram a idéia de colar alguns símbolos, por que devemos duplicar os elementos deste sistema (vamos supor que ele nem é perfeito) ao nível da habilidade do programador no indicador? Se o sistema pode ser simplificado, por que não fazê-lo? Quando a Terra ainda estava de pé sobre três elefantes, o tempo de 5 segundos não foi inventado para nada.

Atualização. Você pode introduzir o prazo de 5 segundos sem histórico e os ticks serão apenas uma vez em 5 segundos, e para testar todo tipo de soluções (compilação do indicador com algum prefixo para trabalhar apenas no 5S, outros indicadores não serão executados nele) - a ideologia existente do terminal não mudará, assim podemos mudar e modificar soluções, e a melhor/optima solução será formada durante os testes.

(LMS para os desenvolvimentos de sua biblioteca, sintéticos, janelas destacadas, etc.). Desenvolvedores).

[fxsaber]

Unicornis:

Mesmo que haja um milhão de carrapatos por minuto, isto não torna a solução impraticável.

[Unicornis]

fxsaber:

Um milhão de carrapatos por minuto não torna a solução impraticável.

A questão não é sobre a exequibilidade da solução. A razoabilidade de chamar o indicador a cada tique atingido antes do qual um número desconhecido de tiquetaques foi perdido, além disso, alguma obsolescência de um tique é considerada? Se algo é pulado (com carga crescente) e a relevância do tick não é conhecida, então esta situação não resolve o problema analítico - se não, por que se preocupar com isso. Em geral, proibir o fluxo de carrapatos nos indicadores, deixar os carrapatos para o indicador da plataforma uma vez a cada 5 segundos - 12 carrapatos por minuto, é suficiente.

[fxsaber]

Unicornis:

A questão não é sobre a exequibilidade da solução. A razoabilidade de chamar o indicador a cada tick atingido antes do qual um número desconhecido de ticks foi perdido, além de alguma obsolescência de um tick é considerada ??? Se algo é pulado (com carga crescente) e não sabemos sobre a relevância do carrapato, então esta situação não resolve o problema analítico - se não, por que se preocupar com ele. Em geral, o fluxo de carrapatos nos indicadores deve ser proibido, os carrapatos que vêm da plataforma a cada 5 segundos devem ser deixados - 12 carrapatos por minuto, é suficiente.

Estupidez.