função alternativa de sono

Novo comentário
 

Olá comunidade MQL4,

Eu encontrei um problema enquanto executava um EA incluindo a função Sleep() no testador de estratégia. Aparentemente o testador não executará o EA corretamente com a inclusão da função Sleep() embutida no código.

Algum codificador presente descobriu um método alternativo da função Sleep() para codificar um EA para "esperar" um certo tempo enquanto o EA está sendo executado no testador?


Obrigado

 
WhooDoo22:

Olá comunidade MQL4,

Eu encontrei um problema enquanto executava um EA incluindo a função Sleep() no testador de estratégia. Aparentemente o testador não executará o EA corretamente com a inclusão da função Sleep() embutida no código.

Algum codificador presente descobriu um método alternativo da função Sleep() para codificar um EA para "esperar" um certo tempo enquanto o EA está sendo executado no testador?

Não há nenhuma razão lógica para dormir() trabalhar no Strategy Tester. . o que você está tentando fazer ? se você está tentando cronometrar um evento, então use o tempo e não tente apenas pausar pelo tempo necessário, não é para isso que serve o sono().
 

Simon,

Uma razão pela qual escolhi usar a função 'Sleep()' foi porque Seconds() retorna valores do último tempo conhecido do servidor (a recuperação de dados do último tempo conhecido do servidor faz com que segundos sejam pulados e/ou pausados). Eu desejo confiabilidade, não generalidade.

O que você diz a isto?


Obrigado.

 
WhooDoo22:

Simon,

Uma razão pela qual escolhi usar a função 'Sleep()' foi porque Seconds() retorna valores do último tempo conhecido do servidor (a recuperação de dados do último tempo conhecido do servidor faz com que os segundos saltem e/ou pausem).

Qual é a sua evidência para isto? você só pode "ver" o tempo para os tempos que têm carrapatos, se não houver carrapatos por 30 segundos então você verá um salto de 30 segundos ... não há nada que você possa fazer sobre isto, é como é. Os tempos para carrapatos no Testador de Estratégia devem ser razoavelmente uniformes, pois os carrapatos não são reais, mas sintetizados.
 

Simon,

Portanto, você escreve, uma razão pela qual eu posso estar chamando estes "saltos" &/ou "pausas" em segundos é porque não são criados carrapatos entre [segundos x] e [segundos y]. Em termos leigos, um tique é criado, agora "segundos x" é salvo. Nenhum tique é criado durante três segundos e depois um tique é criado. Agora o 'segundos y' é salvo. ('segundos y' = (segundos x + três segundos)) como ('segundos x' = (segundos y - três segundos)).

O que você diz a isto?


Por enquanto, estarei considerando minhas opções.

Muito obrigado por suas respostas.

 
  1. Até que você retorne desde o início. Nenhum carrapato é criado no testador. Salve o TimeCurrent() em uma variável estática/comum(global). Próximo tick int deltaSec = TimeCurrent() - anterior.
  2. https://www.mql5.com/en/forum/127483 informou que a DayOfWeek() sempre retorna 5 em testador (definitivamente não o mesmo em indicadores, como é Ask and Bid) . Eu nunca uso QUALQUER dos Segundos(), DayOfWeek() etc. porque você não quer o tempo atual do servidor, você quer o tempo do tick do testador. now = TimeCurrent(), sec = TimeSeconds(now); int DOW=TimeDayOfWeek(now) ...
 
WhooDoo22:

Simon,

Portanto, você escreve, uma razão pela qual eu posso estar chamando estes "saltos" &/ou "pausas" em segundos é porque não são criados carrapatos entre [segundos x] e [segundos y]. Em termos leigos, um tique é criado, agora "segundos x" é salvo. Nenhum tique é criado durante três segundos e depois um tique é criado. Agora o 'segundos y' é salvo. ('segundos y' = (segundos x + três segundos)) como ('segundos x' = (segundos y - três segundos)).

O que você diz a isto?

Sim, pode haver facilmente 3 segundos entre carrapatos, como no mundo real, dê uma olhada em qualquer par de moedas à meia-noite GMT, você verá muitas vezes grandes multi-segundos entre carrapatos . . você pode até mesmo não ter carrapatos por mais de um minuto e faltar barras M1 . . não é uma coisa rara.
 

William,

Muito obrigado por sua resposta.

1. Até o seu retorno desde o início. Nenhum carrapato é criado no testador. Economize o TimeCurrent() em uma variável estática/comum(global). Próximo tick int deltaSec = TimeCurrent() - anterior.

Não entendo o que você quer dizer com "Até que você retorne do início". Você poderia, por favor, explicar?


"Nenhum carrapato é criado no testador".

Não quer dizer que não são criados carrapatos de verdade NUNCA no testador. Você não concordaria que carrapatos artificiais são criados no testador?


"Save the TimeCurrent() em uma variável estática/comum(global)". Próximo tick int deltaSec = TimeCurrent() - anterior".

Salve o TimeCurrent() em uma variável. Quando o próximo tick chegar, int deltaSec =TimeCurrent() - anterior.

A variável "previous" não seria a variável TimeCurrent() é salva para...

deltaSec = TimeCurrent() -(TimeCurrent() salva em uma variável anteriormente)

por favor, esclareça William.


https://www.mql5.com/en/forum/127483 informou que a DayOfWeek() sempre retorna 5 em testador. Eu nunca uso QUALQUER dos Segundos(), DayOfWeek() etc. porque agora você quer a hora atual do servidor, você quer a hora do tick do testador. now = TimeCurrent(), sec = TimeSeconds(now); int DOW=TimeDayOfWeek(now) ...


"você quer o tempo do tick do testador".

Sim, ACREDITO que isto é EXATAMENTE o que eu quero ao testar um EA no testador de estratégia devido ao post de Simon descrevendo o raciocínio por trás dos segundos que parecem saltar e/ou pausar.


now = TimeCurrent(), sec = TimeSeconds(now); int DOW=TimeDayOfWeek(now) ...

Em outras palavras...

sec = TimeSeconds(TimeCurrent()); e DOW = TimeDayOfWeek(TimeCurrent());

O que você diz a isto?


Obrigado
 
WhooDoo22:

now = TimeCurrent(), sec = TimeSeconds(now); int DOW=TimeDayOfWeek(now) ...

Em outras palavras...

sec = TimeSeconds(TimeCurrent()); e DOW = TimeDayOfWeek(TimeCurrent());

Dê uma olhada no que o TimeSeconds() lhe dá, depois pense no que o TimeCurrent() lhe dá. . qual deles você precisa e por quê ?
 
WhooDoo22:

Não entendo o que você quer dizer com "até que você volte do início". Poderia explicar por favor"?

Nenhum tic tac é criado no testador" Você não quer dizer que nenhum tic tac real é criado no testador. Você não concordaria que os carrapatos artificiais são criados no testador?

  1. int start(){
   // do something
   return; // Return from start.
}
    int start(){
   // do something
   // Fall off the end is a Return from start.
}
  2. Nenhum carrapato de qualquer tipo é criado até que você retorne e ele cria o próximo e chama seu início(). Se você computar por 5 minutos e retornar o volume (contagem de ticks) na próxima chamada será +1. Em um gráfico ao vivo, se você computar por 5 minutos, então você perderá 5 minutos de carrapatos e na M1 várias novas barras terão se formado.
 
RaptorUK:
Não há nenhuma razão lógica para dormir() para trabalhar no Testador de Estratégia ...

cuidado com tal afirmação. há sempre uma razão lógica para executar o sono(). no Testador e até mesmo nos indicadores. certo, para o caso de uso do OP você não deve brincar com o sono mas não pode generalizar isso para todos os MQL.

quando precisamos dormir no Tester? se, por exemplo, eu testar um roteiro que interage com um EA em teste, talvez eu tenha a necessidade de sincronizar o estado. estou falando de mutexes. para adquirir um mutex de forma limpa ambas as partes precisam da capacidade de esperar, ou seja, de usar o sono.

o mesmo se aplica aos indicadores. não importa que o indicador funcione na rosca UI. se dois fios precisam sincronizar ambos precisam da capacidade de "dormir". e dormir() é a única solução limpa se você tiver que esperar por uma determinada quantidade de ciclos de CPU, as construções "para" apenas demonstram falta de conhecimento.

ok, vamos dar um exemplo prático: meus EA podem exibir o estado da ordem (setas auto-desenhadas etc.). eles o fazem respondendo a comandos externos "enviados" através de descrições de texto de objetos gráficos (1 ordem pendente, 2 posições abertas, 3 posições fechadas, 4-tudo juntos), é por isso que eu o chamo de comandos gráficos. ou eles podem iniciar/parar/resumir seqüências de ofícios respondendo a outros comandos ("start", "stop", "resume"). para ler os comandos eles precisam sincronizar o acesso a esses objetos gráficos (criar objeto gráfico + definir propriedade de texto não é uma operação atômica). e é claro que eu gostaria de testar esse comportamento no Testador, então eu preciso dormir() para esperar.

o mesmo para indicadores rodando no Tester ou online. se eles fizerem algo semelhante eu "tenho que" parar a thread UI para obter um estado limpo, 10 miilissegundos não importam. btw: uma implementação mutex limpa verifica o tempo que já está esperando, quebra o loop e sinaliza um erro se não puder obter um bloqueio de sincronização após alguns segundos.

int seconds;

// run until the lock is aquired
while (true) {
   ...
   // warn every second and cancel after 10 seconds
   duration = GetTickCount() - startTime;
   if (duration >= seconds*1000) {
      if (seconds >= 10)
         return(_false(catch("AquireLock(5)   failed to get lock for mutex \""+ mutexName +"\" after "+ DoubleToStr(duration/1000.0, 3) +" sec., giving up", ERR_RUNTIME_ERROR)));
      warn(StringConcatenate("AquireLock(6)   couldn't get lock for mutex \"", mutexName, "\" after ", DoubleToStr(duration/1000.0, 3), " sec., retrying..."));
      seconds++;
   }
   //debug("AquireLock()   couldn't get lock for mutex \""+ mutexName +"\", retrying...");

   if (IsTesting() || IsIndicator()) SleepEx(100, true);          // expert or indicator under test
   else                              Sleep(100);
}

uso esses comandos escrevendo um script e atribuindo-lhe uma tecla de atalho. então, se eu quiser controlar um especialista/indicador eu só preciso acertar uma tecla, por exemplo. ALT-O para alternar o modo de exibição de ordem entre todos os valores possíveis. ou tenho um script "start" e um "stop" nos favoritos e start/stop/resume uma ea por um clique do mouse.

no testador para ex. uma ea com VisualMode=On em velocidade total irá quase imediatamente falhar se não estiver devidamente sincronizado.

1234
Novo comentário