Erros, bugs, perguntas - página 2179

[Artyom Trishkin]

Nikolai Semko:

Não, não tem nada a ver com o carregamento.

Se não aceitar uma barra de partida zero, mas digamos 50 barras, então está tudo bem. Instantâneo.

E se eu o levar até 30 bar, inclusive, congela. Depois disso, não.

É DEFINITIVAMENTE UM INSECTO!

Experimente este:

//+------------------------------------------------------------------+
//| Возвращает смещение бара по времени                              |
//| https://www.mql5.com/ru/code/1864                                |
//+------------------------------------------------------------------+
int iBarShift(const string symbol_name,const ENUM_TIMEFRAMES timeframe,const datetime time,bool exact=false)
  {
   datetime last_bar;
   if(!SeriesInfoInteger(symbol_name,timeframe,SERIES_LASTBAR_DATE,last_bar))
     {
      datetime array[1];
      if(CopyTime(symbol_name,timeframe,0,1,array)==1)
         last_bar=array[0];
      else
         return WRONG_VALUE;
     }
   if(time>last_bar)
      return(0);
   int shift=Bars(symbol_name,timeframe,time,last_bar);
   datetime array[1];
   if(CopyTime(symbol_name,timeframe,time,1,array)==1)
      return(array[0]==time ? shift-1 : exact && time>array[0]+PeriodSeconds(timeframe) ? WRONG_VALUE : shift);
   return WRONG_VALUE;
  }
//+------------------------------------------------------------------+

[Nikolai Semko]

Artyom Trishkin:

Experimente este:

O que é que o iBarShift tem a ver com qualquer coisa?

É sobre um bug na função de Barras padrão

[Artyom Trishkin]

Nikolai Semko:

O que é que o iBarShift tem a ver com qualquer coisa?

É sobre um bug na função de Barras padrão

Essa função também usa Bars(). Começou com o análogo de iBarShift()

[Nikolai Semko]

Artyom Trishkin:

Essa função também usa Bars(). No seu caso, tudo começou com o análogo de iBarShift()

Sim, claro, a utilização da contrapartida do iBarShift revelou este problema.

Se utilizar a função iBarShift dada por si, não vai apanhar este insecto, porque apenas um TF é aí utilizado,

E este bug acontece quando se usa diferentes TF nas funções CopyTime e Bars.

Mas os bares devem funcionar normalmente em qualquer altura. Mas o meu exemplo mostra que existe um caso especial, em que o iBar fica pendurado durante dezenas de segundos. E não tem nada a ver com o histórico de carga.

[Vitaly Muzichenko]

Nikolai Semko:

Sim, claro, a utilização da contrapartida do iBarShift revelou este problema.

Se utilizar a função iBarShift dada por si, não vai apanhar este insecto, porque apenas um TF é aí utilizado,

E este bug acontece quando se usa diferentes TF nas funções CopyTime e Bars.

Mas os bares devem funcionar normalmente em qualquer altura. Mas o meu exemplo mostra que existe um caso especial, em que o iBar fica pendurado durante dezenas de segundos. E não tem nada a ver com o histórico de carga.

Isto deve-se muito provavelmente ao carregamento histórico

[Kirill Belousov]

Nikolai Semko:

Sim, claro, a utilização da contrapartida do iBarShift revelou este problema.

Se utilizar a função iBarShift dada por si, não vai apanhar este insecto, porque apenas um TF é aí utilizado,

E este bug acontece quando se usa diferentes TF nas funções CopyTime e Bars.

Mas os bares devem funcionar normalmente em qualquer altura. Mas o meu exemplo mostra que existe um caso especial, em que o iBar fica pendurado durante dezenas de segundos. E não tem nada a ver com o histórico de carga.

Penso que há uma tentativa de sincronização cíclica numa situação em que não há barras no intervalo solicitado - As barras estão a esforçar-se por "trabalhar normalmente" e depois desistem por um timeout ou número de tentativas de sincronização.

Deve verificar os valores por si próprio para evitar chamar Barras em tal caso.

[Nikolai Semko]

Vitaly Muzichenko:

Isto é muito provavelmente devido ao carregamento da história

Não estou de acordo. Não teria sido descarregado novamente durante 22 segundos. Além disso, tenho todo o histórico de todas as TF carregadas por um indicador especial.

Se foi um carregamento, então como podemos explicar que as primeiras 31 barras precisam de ser carregadas e as seguintes não.

[A100]

Nikolai Semko:

Se fosse um sub-carregamento, então como explicar que as primeiras 31 barras precisam de um sub-carregamento e as subsequentes não.

A partir da documentação: Ao solicitar o número de barras num determinado intervalo de datas, apenas são tidas em conta as barras cujo tempo de abertura se encontre dentro desse intervalo.

Assim, o protótipo Bars() devolve zero, o que é interpretado como sem história e ::Bars() no caso do guião, como correctamente observado num post anterior, termina por timeout ou pelo número de tentativas falhadas.

[Nikolai Semko]

Kirill Belousov:

Penso que há uma tentativa de sincronização cíclica quando não há barras no intervalo solicitado - As barras estão a tentar "trabalhar normalmente" e depois desistem por timeout ou número de tentativas de sincronização

A razão de tais casos é que não deve chamar as Barras para verificar pessoalmente os valores.

É bem possível.
Mas há muitas opções.

As barras são uma função muito importante, e é difícil de fazer sem ela. Para ser exacto, pode passar sem ele, mas isso custar-lhe-á muitos recursos.

Deve certificar-se de que funciona perfeitamente.

[Nikolai Semko]

A100:

A partir da documentação: Ao solicitar o número de bares num determinado intervalo de datas, apenas são tidos em conta os bares cujos horários de abertura se situam dentro deste intervalo.

Consequentemente, o protótipo Bars() devolve zero, o que é interpretado como uma falta de história e o guião, como correctamente observado numa mensagem anterior, termina por timeout ou por número de tentativas falhadas.

É evidente que é zero.

E o que - não há problema em demorar 22 segundos a decidir que zero barras num determinado intervalo de tempo?

Existe um bug algorítmico óbvio na implementação interna das Barras.

Devemos enviar um pedido ao Service Desk sobre este assunto - o fim-de-semana está à frente e o assunto pode perder-se na segunda-feira.