Quaisquer dobras normalizadas pelo mesmo algoritmo (por exemplo, via NormalizeDouble) podem ser comparadas diretamente umas com as outras.
Este fato óbvio permite evitar em muitos casos construções dispendiosas de comparação de números reais. O que, em algumas tarefas, pode aumentar significativamente o desempenho.
Talvez uma das tarefas mais exemplares seja a de Tester. Vamos analisá-lo através do exemplo.
Existe o BuyLimit. A cada tick, o testador deve comparar o BuyLimit com o preço Ask. O testador padrão o faz desta forma no momento
pass 0 returned result 100000.000000in0:00:01.578
pass 1 returned result 100000.000000in0:00:00.759
pass 2 returned result 100000.000000in0:00:00.894
pass 3 returned result 100000.000000in0:00:00.769
pass 4 returned result 100000.000000in0:00:00.806
pass 5 returned result 100000.000000in0:00:00.772
pass 6 returned result 100000.000000in0:00:01.253
pass 7 returned result 100000.000000in0:00:01.200
pass 8 returned result 100000.000000in0:00:01.089
pass 9 returned result 100000.000000in0:00:00.780
pass 10 returned result 100000.000000in0:00:01.258
optimization finished, total passes 11
optimization done in0 minutes 11 seconds
shortest pass 0:00:00.759, longest pass 0:00:01.578, average pass 0:00:01.014
Sem normalização.
pass 0 returned result 100000.000000in0:00:01.743
pass 1 returned result 100000.000000in0:00:00.844
pass 2 returned result 100000.000000in0:00:00.672
pass 3 returned result 100000.000000in0:00:00.817
pass 4 returned result 100000.000000in0:00:00.635
pass 5 returned result 100000.000000in0:00:00.604
pass 6 returned result 100000.000000in0:00:00.867
pass 7 returned result 100000.000000in0:00:00.611
pass 8 returned result 100000.000000in0:00:00.899
pass 9 returned result 100000.000000in0:00:00.649
pass 10 returned result 100000.000000in0:00:00.742
optimization finished, total passes 11
optimization done in0 minutes 09 seconds
shortest pass 0:00:00.604, longest pass 0:00:01.743, average pass 0:00:00.825
Podemos ver que o ganho é superior a 20% se não fizermos a normalização ao comparar os preços.
Como conseqüência, se o Testador interno for mudado para preços normalizados e não fizer normalização interna ao comparar preços, uma séria melhoria de desempenho pode ser alcançada.
O que a lógica da EA tem a ver com isso? Estamos medindo a velocidade do testador.
É assim que um agente trabalha, conta consecutivamente a mesma coisa. Se você tirar toda a aleatoriedade, o desempenho líquido é próximo do mais curto.
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
Atualizado para 2269. Resultados do perfilador de uma grande EA (não sintética).
Testador
Virtual
Provavelmente, o perfilador faz medições erradas. Caso contrário, o OrderSend cinco leva em média 912 ms.
Quaisquer dobras normalizadas pelo mesmo algoritmo (por exemplo, via NormalizeDouble) podem ser comparadas diretamente umas com as outras.
Este fato óbvio permite evitar em muitos casos construções dispendiosas de comparação de números reais. O que, em algumas tarefas, pode aumentar significativamente o desempenho.
Talvez uma das tarefas mais exemplares seja a de Tester. Vamos analisá-lo através do exemplo.
Existe o BuyLimit. A cada tick, o testador deve comparar o BuyLimit com o preço Ask. O testador padrão o faz desta forma no momento
Isto é, qualquer nível comercial(ordem pendente ou SL/TP) aciona uma Normalização.
Mas podemos sempre sobreviver com uma construção comparativa muito eficaz se os preços tiverem sido normalizados de antemão (antes do backtest).
if (BuyLimit_Price >= Ask) BuyLimit -> Buy;Vamos tentar uma comparação. Eu executei este robô no equipamento de teste através do Virtual.
Comparação de preços através da normalização.
Sem normalização.
Podemos ver que o ganho é superior a 20% se não fizermos a normalização ao comparar os preços.
Como conseqüência, se o Testador interno for mudado para preços normalizados e não fizer normalização interna ao comparar preços, uma séria melhoria de desempenho pode ser alcançada.
Após a atribuição direta sem tapete. operações também
O prefixo, naturalmente, copia a representação do número de bytes inalterado.
Devemos fazer um teste por mais de um segundo para maior clareza?
Há um spread de 3 vezes em uma versão: passe mais curto 0:00:00.604, passe mais longo 0:00:01.743. o que podemos comparar?
Devemos fazer um teste por mais de um segundo para maior clareza?
Há um spread de 3 vezes em uma versão: passe mais curto 0:00:00.604, passe mais longo 0:00:01.743. o que podemos comparar?
Comparando o mais curto, é claro. Estou acostumado a correr com carrapatos filtrados. Preparará os não filtrados mais tarde.
Comparando o mais curto, é claro.
Por quê? A otimização não consiste em um único passe. Que diferença faz que um passe seja tão rápido, se a média não é muito diferente.
Estou acostumado a correr com carrapatos filtrados. Prepararei os não filtrados mais tarde.
Posso apenas fazer um intervalo maior. Pelo menos 30 segundos para o teste.
Por quê? Não é como se a otimização consistisse em um passe. Que diferença faz que um passe seja tão rápido, se a média não é muito diferente.
Este parâmetro é otimizado.
E isso não afeta a lógica. É por isso que é o mais curto.
Este parâmetro é otimizado
E isso não afeta a lógica. É por isso que é o mais curto.
O que a lógica da EA tem a ver com isso? Estamos medindo a velocidade do testador.
O que a lógica da EA tem a ver com isso? Estamos medindo a velocidade do testador.
É assim que um agente trabalha, conta consecutivamente a mesma coisa. Se você tirar toda a aleatoriedade, o desempenho líquido é próximo do mais curto.