Optimização no Testador de Estratégia - página 8
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Agora o teste do exemplo acima tem uma sobrecarga do sistema de cerca de 1,5 segundos no arranque para preparar todos os dados (autorização e sincronização dos dados de cálculo). A questão é que os agentes de teste são completamente independentes e desligados do terminal, o que leva à necessidade de transferir e sincronizar completamente todos os dados utilizados.
Não podemos dizer que o optimizador genético ou testador é lento nos cálculos super rápidos em vários segundos, uma vez que a sobrecarga do sistema tem uma séria influência no tempo final de cálculo. Em cálculos longos de 20 segundos ou mais por corrida, o impacto da sobrecarga do sistema é reduzido a valores negligenciáveis.
Com cada construção, reduzimos este tempo armazenando a maior parte dos dados directamente nos agentes. Penso que resolveremos esta questão em breve.
GA de joo já é mais rápido que o padrão, e quando o código é transferido para CPP pelo Studio 10 (adaptado às CPUs multi-core) a aceleração é outra 6 vezes mais rápida.
É sem ambiente de mercado que se pode arranjar uma calculadora de velocidade personalizada para uma tarefa específica.
Mas quando se tenta fazer um motor de negociação universal com fornecimento a pedido de quaisquer dados de poti multi-moeda com cálculo automático de lucros/limites e relatórios, a velocidade cairá imediatamente em 2-3-4 ordens de magnitude.
Agora, a execução de testes no exemplo acima tem uma sobrecarga do sistema de cerca de 1,5 segundos no início para preparar todos os dados (autorização e sincronização dos dados de cálculo). A questão é que os agentes de teste são completamente independentes e desligados do terminal, o que leva à necessidade de transferir e sincronizar completamente todos os dados utilizados.
Não podemos dizer que o optimizador genético ou testador é lento nos cálculos super rápidos em vários segundos, uma vez que a sobrecarga do sistema tem uma séria influência no tempo final de cálculo. Em cálculos longos de 20 segundos ou mais por corrida, o impacto da sobrecarga do sistema é reduzido a valores negligenciáveis.
Com cada construção, reduzimos este tempo armazenando a maior parte dos dados directamente nos agentes. Penso que resolveremos esta questão em breve.
Sem um ambiente de mercado, é possível criar um contador de disparo rápido personalizado para uma tarefa específica.
Mas ao tentar fazer um motor de negociação universal com fornecimento a pedido de quaisquer dados multimoedas com cálculo automático de lucro/limite e relatórios, a velocidade cairá imediatamente em 2-3-4 ordens de magnitude.
Renat, não quero dizer que leve tempo a preparar o ambiente de mercado e outros "travões" inevitáveis, escrevi na página anterior:
Muito provavelmente, uma diferença tão monstruosa deve-se ao facto de o testador, para além dos cálculos directos FF, necessitar de escrever registos, mostrar informação, etc., que está presente "travagem forçada".
2010.11.28 17:38:30 Passe genético Core 1 (424, 98130899813578) resultado devolvido 48,16 em 2059 ms
2010.11.28 17:38:30 Core 2 genetic pass (426, 990006720) iniciado
2010.11.28 17:38:30 núcleo 2 passe genético (425, 56291461) resultado devolvido 26,67 em 2012 ms
2010.11.28 17:38:28 core 2 genetic pass (425, 56291461) iniciado
2010.11.28 17:38:28 núcleo 2 passe genético (423, 1510001908) resultado devolvido 49.98 em 2028 ms
2010.11.28 17:38:28 núcleo 1 passe genético (424, 98130899813578) iniciado
2010.11.28 17:38:28 núcleo 1 passe genético (422, 1668020166802) resultado devolvido 48,36 em 2013 ms
2010.11.28 17:38:26 núcleo 2 passe genético (423, 1510001908) iniciado
2010.11.28 17:38:26 core 2 genetic pass (419, 99260769921339) resultado devolvido 49,22 em 1935 ms
2010.11.28 17:38:26 núcleo 1 passe genético (422, 1668020166802) iniciado
2010.11.28 17:38:26 núcleo 1 passe genético (418, 32073563420604) resultado devolvido 26,13 em 1934 ms
2010.11.28 17:38:24 Passe genético do testador (421, 730000073) encontrado em cache com resultado 50.00
2010.11.28 17:38:24 Passe genético do testador (420, 2080000208) encontrado em cache com resultado 50.00
2010.11.28 17:38:24 Passe genético Core 2 (419, 99260769921339) iniciado
2010.11.28 17:38:24 2010/11/28 17:38:24 Core 2 genetic pass (417, 99249619924961) resultado devolvido 49,26 em 2059 ms
2010.11.28 17:38:24 núcleo 1 passe genético (418, 32073563420604) iniciado
2010.11.28 17:38:24 núcleo 1 passe genético (416, 2479846771) resultado devolvido 48,49 em 2309 ms
2010.11.28 17:38:22 core 2 genetic pass (417, 99249619924961) iniciado
Ou seja, demora mais de 2 segundos a calcular o FF nu, e isto enquanto não há qualquer referência ao ambiente do mercado.
O optimizador resolve uma tarefa tão simples como f(x1,x2)=x1*x1+x2*x2 algures no 500º "passe" e continua a tentar variantes, uma vez que definiu mais de 1000 variantes para serem calculadas.
E não há definições que afectem as capacidades de pesquisa do algoritmo, além disso, o limite de 64 parâmetros optimizáveis é frustrante.
É possível criar uma calculadora de velocidade personalizada para uma tarefa específica sem um ambiente de mercado.
Mas quando se tenta fazer um motor de negociação universal com fornecimento de quaisquer dados de várias moedas a pedido com cálculo automático de lucros/limites e relatórios, a velocidade cairá imediatamente em 2-3-4 ordens de magnitude.
Não vou discutir, mas seria bom expandir os parâmetros de controlo do algoritmo, as mesmas definições de saída de pesquisa e o número de parâmetros de pesquisa.
Nós aqui no mql5 estamos a trabalhar em algoritmos para procurar 3000 parâmetros, e não é o limite, claro que não em codificação binária mas em plano contínuo.
E ainda tem um SRR nas suas mãos.
Tentei fazê-lo em codificação binária, mas a GA perde em tal caso no mql5. A procura contínua é boa porque ela própria reduz o passo na convergência. Além disso, não precisamos de recursos para a codificação/descodificação. Bem, em geral precisamos de testes correctos, é demasiado cedo para dizer alguma coisa com certeza.
O optimizador genético tornar-se-á provavelmente mais personalizável + minimizaremos a sobrecarga do sistema.
Muito obrigado. Isto é de facto muito importante, mais importante do que muitos possam pensar.
E esperemos também esquecer o "Threshold 64" em algum momento.
Na nova construção do 366 (na segunda-feira), reduzimos a sobrecarga do sistema a valores mínimos.
O perito em genética acima passa agora entre 200 e 300 ms em vez de 2 segundos por passagem.
Muito obrigado. É realmente muito importante, mais importante do que muitos possam pensar.
E esperemos também esquecer o Threshold 64 em algum momento.
Esqueça-o agora mesmo, com 4 parâmetros a 8 dígitos o testador dá um aviso de que o sobredimensionamento excedeu o comprimento.
Assim, para outras necessidades para além de testar EAs, escreva um optimizador personalizado.
E 64 parâmetros são suficientes para optimizar os EAs.
Sim, eu li o fio, onde só podem ser encontrados tais conselheiros com tantos parâmetros:)
Sim, eu li o fio, onde é que eles arranjam conselheiros com tantos parâmetros:)