O que deve ser acrescentado para apoio adicional de cálculos matemáticos universais em MQL5 e MQL5 Cloud Network? - página 2
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
É um pouco diferente. O que eu queria fazer era controlar o curso da optimização.
Grosseiramente falando, quer a sua genética?
Originalmente, sim, foi-lhe pedida a genética.
E utilizá-lo-ia apenas para auto-optimização (seleccionando áreas de parâmetros com base em resultados anteriores).
E eu utilizaria apenas para auto-optimização (seleccionar áreas de parâmetros com base em resultados anteriores).
Grosseiramente falando, quer a sua genética?
Nesta direcção, mas nem tudo é tão unilateral.
Em primeiro lugar, se a AG padrão estivesse satisfeita com tudo (~10K parâmetros completos, optimização multi-parâmetros) então a maioria dos insatisfeitos seria silenciada.
Mas há mais um inconveniente, por vezes quer-se parar a optimização por algum tipo de instinto, e continuar ainda mais. Aqueles que façam correcções manuais ao FF automático.
Se isso também acontecer, mesmo uma pequena parte dos utilizadores exigentes irá finalmente encerrar a questão com a GA.
E não deixe que os criadores se envergonhem por um pequeno número de utilizadores insatisfeitos, são geralmente os mais avançados e é a eles que se deve prestar atenção.
ZZY Mas, de facto, tem razão, a sua genética mais próxima do corpo, e corrê-la nos cludes seria fixe. A propósito, então seria possível resolver o problema com testes de valk-forward por conta própria e não ter de implorar este modo da MQ.
E não deixe que os criadores se envergonhem com o facto de haver poucas pessoas insatisfeitas, geralmente as mais avançadas.
de facto, este factor é o mais importante no processo de rejeição.
Em essência, terão de ser distraídos por uma tarefa que será utilizada por um círculo estreito de pessoas avançadas.
Na realidade, este é o factor mais importante nas recusas.
Em essência, terão de ser distraídos por uma tarefa que será utilizada por um círculo estreito de utilizadores avançados.
É isso mesmo, um utilizador avançado vê mais do que um novato, ao longo do tempo a sua visão dos problemas vai-se espalhar a outros e também vai querer utilizar a funcionalidade que o utilizador avançado já quer utilizar.
Se se concentrar no mainstream, a plataforma estará sempre mais ou menos no passado.
Antes da Kodak ter criado uma saboneteira e uma rede de máquinas de revelação, os turistas não tinham vontade de tirar fotografias eles próprios, era uma prerrogativa dos utilizadores avançados e dos profissionais da fotografia (dos quais havia muitos em qualquer atracção turística).
Mas apareceu um inovador e criou um novo serviço, virando assim a indústria de pernas para o ar e promovendo-a junto das massas.
Isso é o engraçado, um utilizador avançado vê mais do que um novato, com o tempo a sua visão dos problemas vai-se espalhar a outros e também eles vão querer utilizar a funcionalidade que um utilizador avançado já quer utilizar.
Se se concentrar no mainstream, a plataforma estará sempre mais ou menos no passado.
O principal é que antes da Kodak criar a saboneteira e a sua rede de máquinas de revelação, os turistas não tinham qualquer desejo de tirar as suas próprias fotografias - era uma prerrogativa dos utilizadores avançados e dos profissionais da fotografia (dos quais havia muitos em qualquer atracção turística).
Mas apareceu um inovador e criou um novo serviço, virando assim a indústria de pernas para o ar e promovendo-a junto das massas.
Concordo. Com ambos. :)))
A interface deve ser pensada. O que é a genética personalizada? Se a interface com a claude a fazer ao nível de "SetPopullationForCalc(); GetPopulationFitnessFuncs();" então um esquema flexível e poderoso não funcionará.Seria melhor implementar a troca com claud no nível de pacotes de tarefas de volume aleatório onde o tamanho da população não é fixo e é passado como parâmetro juntamente com a matriz de parâmetros. Além disso, precisamos de nos separar completamente (finalmente!!) "optimização" e "teste", com a possibilidade (em paralelo arbitrária!) de alternar e combinar pedidos de (1) computação de multidões leves em massa (análogo de optimização) de conjuntos de parâmetros com (2) execuções individuais detalhadas (análogo de "teste"). Depois, os avanços em massa são construídos sem problemas, e todo o resto caca com chá que mesmo agora não me vem à mente.
Estes são os pensamentos.
A conclusão é a seguinte: pense numa camada de api flexível entre o testador e os programas no terminal. Isto resolverá o antigo problema de "iniciar a optimização genética no decurso do comércio com correcção on-the-fly dos parâmetros dos robôs", juntamente com outros problemas discretamente.Em particular, a Nuvem tornar-se-á um mega-computador super-universal de mercado de massas, capaz de resolver tarefas arbitrárias com grandes volumes de cálculos de tipo único.
Para uma boa auto-optimização, o testador tem de ser atirado para fora da cadeia.
Não estou a falar da auto-optimizaçãoda EA em tempo de execução, mas, por exemplo, da "wolf-forward" por sua conta e risco.
A selecção de gamas de parâmetros para execuções futuras resolveria este problema a 100% (as datas podem ser limitadas programmaticamente usando os mesmos parâmetros).
Mas isto, dado o uso de cludes, não é tão simples e inequívoco como parece.
Não estou a falar da auto-optimizaçãoda EA enquanto está a decorrer, mas, por exemplo, de a encaminhar internamente.
Um, é o mesmo do meu ponto de vista :)
Em primeiro lugar, se a AG padrão fosse satisfeita em tudo (~10K parâmetros completos, optimização multi-parâmetros) então a maioria dos insatisfeitos seriam silenciados.
Sim, a maioria dos 5-10 insatisfeitos :)