O que deve ser acrescentado para apoio adicional de cálculos matemáticos universais em MQL5 e MQL5 Cloud Network? - página 7
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
para usar o meu PC no Cloud Computing em
MQL5 Cloud Network. Mas aqui está o problema, a minha conta emhttp://www.mql5.com não mostra agentes, o que significa que não serei cobrado pela utilização do meu PC. Introduzi o nome da minha conta no próprio MT5MetaTrader 5 Agents Manager.
Mas aqui está o problema na minha conta emhttp://www.mql5.com não estão expostos agentes, o que significa que a taxa não vai pingar pela utilização do meu PC. No próprio MT5MetaTrader 5 Agents Manager, introduzi o nome da minha conta.
Daí a questão - que outras funções devem ser incluídas para melhorar as capacidades da grelha de facturação?
Provavelmente métodos de classes que podem ser chamados remotamente e obter os seus valores de agentes: Remote Procedure Call (RPC). Algo parecido com isto:
Juntamente com uma chamada de método, evidentemente, precisamos de passar os valores actuais do campo do objecto que chama o método remotamente ao agente.
A ideia é que a instância principal da classe chama algum método, e dentro do método, são criadas instâncias de outras classes, que enviam tarefas para a nuvem. O(s) resultado(s) é(são) devolvido(s).
Por exemplo, uma tarefa é criada sob a forma de cálculo de várias jogadas de xadrez. No método principal, que é executado remotamente, são criadas várias combinações com uma contagem para um movimento sob a forma de objectos de alguma classe e enviados. Aqueles, por sua vez, se o movimento não terminou com um resultado ou a profundidade de cálculo não excedeu o limite, chamam de novo o mesmo método. E por aí adiante e assim por diante.
Sem o envolvimento do terminal, isto é uma coisa boa.
Quem irá gerar os dados para este "um dos agentes"? Será que um guião ou indicador será capaz de o fazer?
Qualquer um dos agentes pode gerar dados em bruto para os outros. Pode ser enviado ou por transmissão prévia a todos ou a um agente seleccionado.
Qualquer agente poderá enviar quadros de dados a quaisquer outros agentes.
Qual é a finalidade da comunicação agente a agente, ilumine os ignorantes se puder.
Para tarefas relacionadas onde seja necessário o intercâmbio de dados/resultados de cálculos anteriores.
Não tem de estar na nuvem. Pode fazer uma rede de agentes de alta velocidade na sua área local e executar uma tarefa complexa com muita troca de dados sobre a mesma.
Como resultado, pode construir uma rede poderosa sem supercomputadores.
Provavelmente, métodos de classe que podem ser chamados remotamente e obter os seus valores de agentes. Algo parecido com isto:
Aqui, claro, juntamente com uma chamada de método, teríamos de passar os valores actuais do campo do objecto, que chama este método remotamente, também ao agente.Não, a única opção exequível e realista é o intercâmbio de quadros de dados. A execução remota de funções não é grave, porque ninguém no seu perfeito juízo iria replicar o ambiente de informação.
Como parte do trabalho de enquadramento, a funcionalidade pode ser alargada:
Só para informação:
O custo da latência da rede é tal que, a fim de optimizar o processo global, deve envolver-se em lotes explícitos de resultados e transferir dados tão pouco frequentemente quanto possível. Por exemplo, se houver um problema matemático de alta velocidade (dentro de fracções de segundo) para 100.000.000 passagens, é melhor optimizar imediatamente o processo algoritmicamente em porções de 1.000-10.000 passagens e escrever o código de processamento em lote com resultados devolvidos em lote. Isto daria uma enorme vantagem sobre 100.000.000 de devoluções, onde muito tempo seria gasto na rede.
Pela nossa parte, nós próprios ajudamos seriamente em casos de tarefas de alta velocidade batalhando a saída em dezenas ou centenas de passes para cada agente e também batalhando as respostas. Isto permite enormes poupanças na transmissão da rede e mantém a latência da rede a um mínimo.
Não, a única opção exequível e realista é o intercâmbio de quadros de dados. A execução remota de funções não é grave, porque ninguém no seu perfeito juízo reproduziria um ambiente de informação.
Nem todas as tarefas podem ser embaladas, porque nalgumas aplicações e tarefas muito consumidoras de recursos o resultado pode ser o único ou pode não ser detectado de todo e as tarefas inúteis são descartadas pelo caminho, ou seja, os resultados em falta não devem sequer ser devolvidos.
Depois há outra forma de o fazer. Ou seja, a tarefa principal gera tarefas do seu lado, informa os agentes sobre ela. E os agentes chamam métodos remotos com tarefas, computam e se obtiverem resultados, chamam métodos remotos para devolver os resultados.
Por exemplo, a tarefa: procurar divisores principais de números Fermat. Talvez não haja qualquer resultado, ou um, ou vários. A questão é que a pesquisa destes divisores muito potenciais é uma tarefa muito intensiva em recursos, porque primeiro é necessário criar um objecto sob a forma de um grande número (na tarefa só se pode especificar dois números como inteiros: prime e mantissa, para reduzir o custo da transferência de informação). Depois o número a verificar para prime (realizar um teste simplificado, com a ajuda do qual será revelado que o número é superior a 90% não é prime). E depois, se o teste de simplicidade for aprovado com sucesso, no laço, ao quadrado do modulo procurar uma correspondência. Se a condição antes do fim do laço não coincidir, então não haverá resultado e não haverá nada a devolver. Neste caso, o agente deve solicitar remotamente o próximo trabalho, chamando remotamente o método apropriado a partir da aplicação anfitriã. Se encontrar o resultado, deve chamar outro método e passar o mesmo resultado.
Isto é, as tarefas são diferentes e as estruturas de enquadramento não são adequadas para todos. E o custo da latência da rede no exemplo acima é também negligenciável, uma vez que uma tarefa consiste em passar dois inteiros a um agente.
Nem todas as tarefas podem ser agrupadas, pois em algumas aplicações e tarefas muito intensivas em recursos pode haver apenas um resultado ou nenhum resultado, e as tarefas inconclusivas são descartadas à medida que a peça avança, ou seja, os resultados em falta não precisam sequer de ser devolvidos.
Se utilizar um esquema de moldura, basta não devolver resultados vazios ao "agente servidor" ou apenas devolver a bandeira "pacote calculado, sem dados".
Está ciente de como funciona o modo frame? O cabeçalho da EA começa mesmo na janela do terminal e espera por respostas (molduras de dados) de agentes remotos. Ou seja, a parte do servidor senta-se no gráfico, recebe dados e pode visualizar qualquer coisa.
Leia e experimente por si mesmo: https://www.mql5.com/ru/code/914
Se utilizar um esquema de frames, basta não devolver resultados vazios ao "agente servidor".
Bem, essa é apenas a base. As principais tarefas, que são muito computacionalmente intensivas, são recursivas. E a nuvem não é destinada a tais tarefas porque foi concebida apenas para a busca completa. Em muitas tarefas aplicadas não utilizamos a força bruta, uma vez que não tem perspectiva. Tarefas recursivas são necessárias para a busca em profundidade e em largura e em profundidade com largura. Por exemplo, a síntese de moléculas. Isto é, uma árvore de soluções potenciais é construída no decurso da peça, cada ramo é computacionalmente intensivo em recursos. Mas nem todos os ramos são eficazes. Ou seja, a busca pára algures, mas ao mesmo tempo, a busca continua para outros ramos potenciais em profundidade ou largura.
A pesquisa completa praticamente nunca é utilizada em qualquer lugar, uma vez que para a maioria das tarefas de aplicação não levará tempo suficiente para encontrar uma solução (por exemplo, problema com a análise de jogadas de xadrez). Mas os métodos recursivos com corte de ramos de solução não prospectiva dão alta velocidade, especialmente nos cálculos distribuídos. É por isso que se quiser atrair engenheiros de aplicação para a nuvem, deve ajustar a nuvem às suas tarefas, em vez de pensar que eles deixarão tudo e tentarão todas as variantes numa fila, independentemente das suas perspectivas. Será mais fácil para eles criar a sua própria rede de computação distribuída, mesmo que seja menos rápida em termos de gigaflops e tenha menos computadores, mas será mais eficiente, porque procurará apenas em direcções promissoras e encontrará a solução necessária muito mais rapidamente do que a Cloud Network. E muitas linguagens de programação têm um kit de ferramentas para isto, ou seja, implementações RPC prontas.
Por exemplo, a mesma procura de divisores principais de números Fermat pode ser dividida em subtarefas. A aplicação principal gera as tarefas. A camada seguinte cria objectos e executa uma verificação rápida e simples dos mesmos a partir das restantes tarefas. A camada seguinte procura condições, ou seja, se é encontrado ou não um divisor de um número Fermat. Os empregos são novamente gerados a partir dos números encontrados. A camada seguinte efectua uma verificação de simplicidade completa, e se o número não for primo, gera empregos. Se for primordial, devolve o resultado à aplicação principal. A camada seguinte factoriza os divisores não simples dos números Fermat e gera empregos para a camada anterior a partir deles.
Isto cria um transportador, onde cada agente de camadas desempenha as suas tarefas. Não está claro se o resultado será encontrado. O que é importante é que os números de soluções são descartados na esteira. Por outras palavras, poupa muitos recursos computacionais, em vez de tentar empilhar milhares de agentes em tarefas pouco prometedoras e tentar moê-los.
Essa é apenas a base. As principais tarefas são recursivas e muito consumidoras de recursos para cálculos. E a nuvem não é destinada a tais tarefas porque foi concebida apenas para a busca completa. Em muitas tarefas aplicadas não utilizamos a força bruta, uma vez que não tem perspectiva. Tarefas recursivas são necessárias para a busca em profundidade e em largura e em profundidade com largura. Por exemplo, a síntese de moléculas. Isto é, uma árvore de soluções potenciais é construída no decorrer da peça, cada ramo é computacionalmente intensivo em recursos. Mas nem todos os ramos são eficazes. Ou seja, algures onde a busca pára, mas ao mesmo tempo, a busca continua para outros ramos potenciais em profundidade ou largura.
Cálculos de lotes em 1.000-10.000 passes, e devolvem apenas os resultados significativos. Esta é uma técnica algorítmica muito eficaz.
Escrevi sobre isso especificamente acima.
A pesquisa completa quase nunca é utilizada, porque para a maioria dos problemas aplicados não levará tempo suficiente para encontrar uma solução (por exemplo, um problema de análise de jogadas de xadrez). Mas os métodos recursivos com corte de ramos de solução não prospectiva dão alta velocidade, especialmente nos cálculos distribuídos. É por isso que se quiser atrair engenheiros de aplicação para a nuvem, deve ajustar a nuvem às suas tarefas, em vez de pensar que eles deixarão tudo e tentarão todas as variantes numa fila, independentemente das suas perspectivas. Seria mais fácil para eles criar a sua própria rede de computação distribuída, mesmo que seja menos rápida em termos de gigaflops e tenha menos computadores, mas é mais eficiente, porque procurará apenas em áreas promissoras e encontrará a solução necessária muito mais rapidamente do que a Cloud Network. E muitas linguagens de programação têm um kit de ferramentas para isto, ou seja, implementações prontas de RPC.
Por exemplo, a mesma procura de divisores principais de números Fermat pode ser dividida em subtarefas. A aplicação principal gera as tarefas. A camada seguinte cria objectos e executa uma verificação rápida e simples dos mesmos a partir das restantes tarefas. A camada seguinte procura condições, ou seja, se é encontrado ou não um divisor de um número Fermat. As tarefas são novamente formadas a partir dos números encontrados. A camada seguinte efectua uma verificação de simplicidade completa, e se o número não for primo, gera empregos. Se for primordial, devolve o resultado à aplicação principal. A camada seguinte factoriza os divisores não primários dos números de Fermat e gera empregos para a camada anterior.
Leia acima sobre o intercâmbio de dados e a demonstração:
É proposta uma extensão adicional ao intercâmbio de dados para que o processo principal possa, adicionalmente, passar quaisquer dados personalizados adicionais a qualquer agente. Como resultado, é possível ler em partes, aplicando novas condições personalizadas a agentes remotos. Como resultado, pode ler da maneira que quiser, mudando as condições de cada vez.
Mais uma extensão possível, quando os agentes podem não só receber tarefas do mestre, mas também trocar dados entre si. É claro que o pode fazer através de wizard (que pode ser muito lento se houver muitos dados), mas é ainda mais eficiente e rápido fazê-lo directamente através de servidores de nuvens.
Renat:
Outra extensão possível é que os agentes não só recebam tarefas do feiticeiro, mas também transfiram dados entre si. É claro que pode fazê-lo através do feiticeiro (que pode ser muito lento se houver muitos dados), mas é ainda mais eficiente e rápido fazê-lo directamente através dos servidores de nuvem.
É disto que precisamos, ou seja, transferência recursiva de dados de um agente para outro sem assistente, mas com retorno garantido dos resultados ao mestre. Para que o agente não pudesse pegar numa tarefa e parar de trabalhar sem a completar, por exemplo, porque o computador foi desligado e o ramo da solução potencialmente eficaz foi quebrado.
Isto é, por exemplo, a tarefa de analisar um jogo de xadrez. O feiticeiro organiza as peças e gera tarefas para a cor das peças que se vão mover agora, ou seja, uma peça - uma tarefa. Cada agente, tendo recebido uma tarefa para a sua peça, descarta as variantes não prometedoras para análise posterior, quando uma peça não se pode mover, e forma novas formações que são transmitidas como tarefas para as peças inimigas. E assim por diante, até que o companheiro ou o impasse ou a profundidade da busca seja excedida.
Se tal tarefa for confiada à implementação actual da nuvem, então só poderá gerar pacotes de tarefas para uma pesquisa completa. E a nuvem não tem agentes suficientes para isso, e é improvável que o feiticeiro tenha memória suficiente para agrupar todos esses trabalhos. Porque não existe um mecanismo de peneirar as variantes não prometedoras. Pois com cada novo movimento de peças analisadas, o número de tarefas cresce exponencialmente, mas também uma parte considerável delas é descartada e não gera tarefas sem sentido, como no excesso total de trabalho. E só se pode descobrir por perspectiva depois de mergulhar a alguma profundidade ou largura da árvore de decisão. E a profundidade da implementação desta nuvem é 1, ou seja, de mestre para agente e de volta.
O meu ponto de vista é este. Para o comércio, é também necessária a implementação de pesquisas recursivas com cortes de becos sem saída. É melhor procurar não só um único extremo, mas também um conjunto de extremos locais (de facto há muitos deles). E o espaço de pesquisa para todas as variantes possíveis é astronómico, ou seja, nenhum agente retirado de todas as redes informáticas distribuídas será suficiente. Para o fazer, em cada passo enumeramos os bairros mais próximos de um ponto (coordenadas do ponto - parâmetros de entrada da EA) a alguma distância e espaçados por algum valor angular, para ver se melhoram ou não os resultados em comparação com o actual. Se algum deles for pior ou exceder a profundidade da busca, descartamo-los. Se melhorarem, procuramos de novo e formamos um conjunto de outras tarefas a partir dos pontos melhorados que distribuímos aos agentes. Se um extremo for encontrado localmente (todos os pontos na vizinhança apenas pioram o resultado actual), devolvemos o resultado à aplicação principal. Uma vez identificados os extremos, estes são entregues ao feiticeiro e analisados mais aprofundadamente utilizando testes de avanço.
Tal tarefa não pode ser resolvida directamente, uma vez que o número de variantes é astronómico. Um algoritmo genético também não procura extremos locais (também pára perto do global na vizinhança imediata) e apenas mostra resultados intermédios, independentemente do seu extremo. Não quer dizer que o espaço de busca do algoritmo genético e do algoritmo da força bruta seja limitado e discreto. É a procura do número máximo de extremas locais mas rápido, isto é, com o corte de gerações não prospectivas de tarefas de mestre para agentes e de agente para outros agentes e alcance ilimitado (mas para que as restrições possam ser definidas se necessário, por exemplo, a profundidade de pesquisa em tais algoritmos é sempre limitada). Se a nuvem implementasse a transferência recursiva de empregos, o problema seria resolvido.