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

 
Slava:

É possível tentar determinar.

Se for minutos, você pode comparar o tempo da última barra com o TimeCurrent(). Se não for M1, você pode perguntar ao iTime(_Symbol,PERÍODO_M1,0) e comparar com TimeCurrent().

Você pode comparar o Preço de Licitação ou Último preço (dependendo do símbolo) com o Preço de fechamento da última barra. Você pode pedir diretamente à SymbolInfoTick o símbolo atual. Além da Licitação e da Última, há também o tempo de carrapato

Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.

mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos

 
Igor Makanu:

Obrigado, pelo menos algumas informações sobre onde e como procurar por bugs se algo deu errado.

mas eu acho, que todas as mesmas funções embutidas para verificar o status, ou melhor ainda, seria uma bandeira, como int _LastError, que armazenaria o número de carrapatos perdidos, seria conveniente ao chamar a OnCalculate() - em cálculos complexos, retornar imediatamente, para liberar o fluxo de símbolos

thought, pondered.... qual será o conhecimento dos carrapatos perdidos (Slava diz, que é garantido que o indicador recebe TODOS os carrapatos, e este fato leva a todos os pendências não só dos programas MQL, mas até mesmo do terminal do cliente)? em qualquer caso, esses carrapatos terão que ser coletados e processados, e isso significa, se perdemos um carrapato, por que de repente esperamos que da próxima vez isso seja possível? - é um círculo vicioso.

Eu estava pensando... talvez os desenvolvedores devam introduzir algo semelhante às exceções? A chegada de um novo tick deve interromper todas as operações, os cálculos no indicador naquele momento, e qualquer função MQL padrão deve retornar um erro durante sua execução, se um novo tick vier naquele momento... Então o trabalho com o indicador torna-se claro, conveniente e previsível. Para os outros tipos de programas (scripts, Expert Advisors) é quase desnecessário.

E todo tipo de verificações de carrapatos no indicador por sua relevância - para dizer de forma branda, esta não é a solução.

 

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

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

 
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 com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.

Isto resolverá dramaticamente o problema dos indicadores atrasados, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.

Então, você será capaz de ter um indicador muito rápido com tal design?

//+-------------------------------------------+
int OnInit() 
  {
  EventSetMillisecondTimer(200);
//-
  return(INIT_SUCCEEDED);
 }

//+-------------------------------------------+
int OnCalculate (const int rates_total,
                 const int prev_calculated,
                 const datetime& time[],
                 const double& open[],
                 const double& high[],
                 const double& low[],
                 const double& close[],
                 const long& tick_volume[],
                 const long& volume[],
                 const int& spread[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
  return(rates_total);
 }

//+-------------------------------------------+
void OnTimer()
 {
  // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

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

 
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 com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.

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

E se você fizer uma função padrão para obter uma matriz sincronizada de múltiplas moedas, será um verdadeiro feriado.

 
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 com base no recebimento de um pacote de carrapatos, em vez de em cada carrapato.

Isto resolverá radicalmente o problema dos indicadores lentos, preservando a possibilidade do processamento garantido de cada tick para alguns indicadores.

Boa idéia!

E de preferência deve funcionar sem qualquer#propriedade por padrão.

Se alguém precisa disso de outra forma, então deixe-os colocar#propriedade.

 
A solução para receber carrapatos em pacotes é boa e provavelmente não muito cara, se não precisarmos de tempo real (mas não está claro como os EAs funcionarão com indicadores que funcionam a preços "de ontem", mas não importa).

Mas há outra classe de problemas - em tempo real, a cada tique. Neste caso, ou você tem tempo para fazer cálculos após o tique antes do próximo tique, ou não, e então a solução comercial não será relevante (não há terceira via). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, podemos esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.

 
_o0O:
A solução para receber carrapatos em pacotes é boa e provavelmente não muito cara, se não precisarmos de tempo real (mas não está claro como os EAs funcionarão com indicadores que funcionam a preços "de ontem", mas não importa).

Mas há outro tipo de tarefas - em tempo real, a cada tique. Você tem tempo para fazer estimativas após o recebimento de um tick ou não, e a solução comercial será irrelevante (não há uma terceira alternativa). É por isso que existe apenas uma maneira correta de resolver o problema - interromper todos os cálculos atuais e retornar o erro quando um novo tick chegar. Caso contrário, pode-se esquecer o tempo real. Agora os carrapatos estão ficando cada vez mais rápidos a cada dia, e é um longo caminho a percorrer, por isso é necessário planejar o futuro, sem mencionar o fato de que é impossível processar todos os carrapatos sem atrasos no tempo no presente.

A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para indicadores que trabalham com carrapatos, mas não há muitos deles, para eles é possível alocar"#property tester_everytick_calculate".

E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é racional atrasar todo o trabalho do indicador para o bem de cada tique.

Esperamos por"#property tester_everytick_calculate".

 
Vitaly Muzichenko:

A maior parte dos indicadores EAs trabalha com barra fechada[1], por isso a omissão de carrapatos não importa, é real para os indicadores que trabalham com carrapatos, mas não há muitos deles, eles só podem ser atribuídos"#property tester_everytick_calculate".

E mais uma vez, se você precisar de super-pontas, não precisa de um indicador para isso, tudo isso pode ser escrito no código do Expert Advisor. Portanto, não é razoável retardar o trabalho do indicador para o bem de cada tique.

À espera de"#property tester_everytick_calculate"


OK, e como o que você disse discorda do que eu disse?
 
Pode ser útil para alguém. Tenho um indicador de múltiplas moedas, portanto os principais cálculos capacitivos que faço no bloco de inicialização e somente a renderização em oncalculus. Mas esta é uma solução para situações em que as próprias linhas indicadoras não contêm cálculos complexos. No meu caso é um indicador de carteira exibindo um gráfico de comportamento de carteira.
Razão: