Eu também nunca olho para ela. Mas ocupa um espaço útil...
Ninguém ficará chocado quando primeiro houver mensagens do testador sobre sincronização, carregamento do Expert Advisor, etc. com hora local, e depois há mensagens do Expert Advisor e do servidor de negociação de testes com hora de teste, por vezes intercaladas com mensagens do testador com hora local?
Encontrei um dos locais onde o Testador pode ser acelerado. Acontece que sempre que o Testador compara dois preços (por exemplo, BuyLimit e Tick.ask), fá-lo através de uma dispendiosa normalização. Não há necessidade de fazer isso!
Slava: Ninguém ficará chocado quando primeiro houver mensagens do testador sobre sincronização, carregamento do Expert Advisor, etc. com hora local, e depois há mensagens do Expert Advisor e do Test Trading Server com hora de teste, por vezes intercaladas com mensagens do testador com hora local?
Slava, tenho estado a pensar na melhor maneira de o organizar. Queria sugerir que a hora de início, sincronização, etc., fosse enviada primeiro, e depois o resto - do perito e testador com mensagens importantes.
fxsaber: Encontrei um dos locais onde o Testador pode ser acelerado. Acontece que sempre que o Testador compara dois preços (por exemplo, BuyLimit e Tick.ask), fá-lo através de uma dispendiosa normalização. Não há necessidade de fazer isso!
Os preços no histórico do Terminal não estão normalizados!
Reproduziu um bug com um valor vazio nos parâmetros intu.
1. Montar a EA:
2. optimizar em qualquer coisa ambos os parâmetros:
3. Desmarcar o enam e optimizar apenas x:
4. Carregar a 1ª cache de optimização, depois a 2ª cache de optimização, executar uma única execução a partir dos resultados. Em vez de -1, obtemos INT_MAX:
Relevante para todos os enumerativos que comecem por -1.
Há uma suspeita de que quando se desmarca t, a entrada é completamente desactivada e a variável t contém um valorINT_MAX não-inicializado em vez de um valor vazio.
Estes não são preços tortuosos! Estão bastante normalizadas. Isto é muito claro a partir da sua impressão
O servidor comercial utiliza sempre um epsilon para comparar o preço de entrada com o preço actual ao negociar.
Está ciente de que o resultado de <algum_número_real>*0,5 pode ser diferente do resultado de <o_mesmo_número_real>/2,0?
Está ciente de que alguns compiladores podem substituir uma operação por outra ao optimizar o código? Além disso, num caso é substituído e noutro caso não o é, dentro do mesmo projecto. Sem declarar uma guerra.
Há uma suspeita de que quando se desmarca t, a entrada é completamente desactivada e a variável t contém um valor INT_MAX não-inicializado em vez de um valor vazio.
O motivo que está no interior não é importante.
O que é importante é que o reproduzam e o fixem. O insecto é antigo.
O servidor de comércio utiliza sempre o epsilon ao negociar para comparar o preço de entrada e o preço actual.
É correcto que o servidor de comércio faz exactamente isso.
Está ciente de que o resultado <algum_número_real>*0,5 pode ser diferente do resultado <o_mesmo_número_real>/2,0?
Está ciente de que alguns compiladores podem substituir uma operação por outra ao optimizar o código? Além disso, num caso, substituir e noutro não, dentro do mesmo projecto. Sem declarar guerra.
A resposta a ambas as perguntas é afirmativa - estou ciente disso.
Mais uma vez, os preços originais no Terminal não são normalizados. Por conseguinte, esta situação ocorre facilmente.
Eu também nunca olho para ela. Mas ocupa um espaço útil...
No entanto, veio a calhar.
Eu também nunca olho para ela. Mas ocupa um espaço útil...
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
MetaTrader 5 Strategy Tester: bugs, bugs, sugestões para melhorias
fxsaber, 2019.12.11 04:50
A segunda coluna também falta milissegundos.
Ninguém ficará chocado quando primeiro houver mensagens do testador sobre sincronização, carregamento do Expert Advisor, etc. com hora local, e depois há mensagens do Expert Advisor e do Test Trading Server com hora de teste, por vezes intercaladas com mensagens do testador com hora local?
Slava, tenho estado a pensar na melhor maneira de o organizar. Queria sugerir que a hora de início, sincronização, etc., fosse enviada primeiro, e depois o resto - do perito e testador com mensagens importantes.
A mim parece-me o mesmo que sugeriu :)
Encontrei um dos locais onde o Testador pode ser acelerado. Acontece que sempre que o Testador compara dois preços (por exemplo, BuyLimit e Tick.ask), fá-lo através de uma dispendiosa normalização. Não há necessidade de fazer isso!
Os preços no histórico do Terminal não estão normalizados!
Resultado (EURUSD, MQ-Beta)
Como é isso possível? Um erro no lado do servidor de comércio?
Como consequência, o Testador está a conduzir EAs a preços tortos mesmo com símbolos reais.
Parece que o problema é que os criadores utilizaram um algoritmo de normalização diferente.
Reproduziu um bug com um valor vazio nos parâmetros intu.
1. Montar a EA:
2. optimizar em qualquer coisa ambos os parâmetros:
3. Desmarcar o enam e optimizar apenas x:
4. Carregar a 1ª cache de optimização, depois a 2ª cache de optimização, executar uma única execução a partir dos resultados. Em vez de -1, obtemos INT_MAX:
Relevante para todos os enumerativos que comecem por -1.
Há uma suspeita de que quando se desmarca t, a entrada é completamente desactivada
e a variável t contém um valorINT_MAX não-inicializado em vez de um valor vazio.
Os preços no histórico do Terminal não estão normalizados!
Resultado (EURUSD, MQ-Beta)
Como é isso possível? Um erro no lado do servidor de comércio?
Como consequência, o Testador está a conduzir EAs a preços tortos mesmo com símbolos reais.
Parece que o problema é que os criadores utilizaram um algoritmo de normalização diferente.
Estes não são preços tortuosos! Estão bastante normalizadas. Isto é muito claro a partir da sua impressão
O servidor comercial utiliza sempre um epsilon para comparar o preço de entrada com o preço actual ao negociar.
Está ciente de que o resultado de <algum_número_real>*0,5 pode ser diferente do resultado de <o_mesmo_número_real>/2,0?
Está ciente de que alguns compiladores podem substituir uma operação por outra ao optimizar o código? Além disso, num caso é substituído e noutro caso não o é, dentro do mesmo projecto. Sem declarar uma guerra.
Há uma suspeita de que quando se desmarca t, a entrada é completamente desactivada
e a variável t contém um valor INT_MAX não-inicializado em vez de um valor vazio.
O motivo que está no interior não é importante.
O que é importante é que o reproduzam e o fixem. O insecto é antigo.
Estes não são preços tortuosos! Estão bastante normalizadas. Isto é muito claro a partir da sua impressão
O preço só é normalizado se passar esta condição.
Fórum sobre negociação, sistemas de negociação automatizados e testador de estratégias
MetaTrader 5 testador de estratégia: bugs, bugs, sugestões de melhoria
fxsaber, 2019.12.11 07:47
O servidor de comércio utiliza sempre o epsilon ao negociar para comparar o preço de entrada e o preço actual.
É correcto que o servidor de comércio faz exactamente isso.
Está ciente de que o resultado <algum_número_real>*0,5 pode ser diferente do resultado <o_mesmo_número_real>/2,0?
Está ciente de que alguns compiladores podem substituir uma operação por outra ao optimizar o código? Além disso, num caso, substituir e noutro não, dentro do mesmo projecto. Sem declarar guerra.
A resposta a ambas as perguntas é afirmativa - estou ciente disso.
Mais uma vez, os preços originais no Terminal não são normalizados. Por conseguinte, esta situação ocorre facilmente.
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
Preços não normalizados em MT4
fxsaber, 2019.02.20 23:03
Mas a situação é muito pior e, ao mesmo tempo, no MQ-DemoO preço de abertura da posição actual não é igual ao preço da sua encomenda/comércio.