Que faut-il ajouter pour une prise en charge supplémentaire des calculs mathématiques universels dans MQL5 et MQL5 Cloud Network ? - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
d'utiliser mon PC en Cloud Computing dans
MQL5 Cloud Network. Mais voilà le problème, mon compte surhttp://www.mql5.com n'affiche pas d'agents, ce qui signifie que je ne serai pas facturé pour l'utilisation de mon PC. J'ai saisi mon nom de compte dans le gestionnaire d'agents MT5MetaTrader 5 lui-même.
Mais voici le problème : dans mon compte, surhttp://www.mql5.com, aucun agent n'est affiché, ce qui signifie que la redevance ne sera pas versée pour l'utilisation de mon PC. Dans le gestionnaire d'agents MT5MetaTrader 5 lui-même, j'ai saisi mon nom de compte.
D'où la question : quelles autres fonctions devraient être incluses pour améliorer les capacités de la grille de facturation ?
Probablement des méthodes de classes qui peuvent être appelées à distance et obtenir leurs valeurs à partir d'agents : Remote Procedure Call (RPC). Quelque chose comme ça :
Avec l'appel d'une méthode, nous devons bien sûr transmettre à l'agent les valeurs actuelles des champs de l'objet qui appelle la méthode à distance.
L'idée est que l'instance de la classe principale appelle une méthode, et qu'à l'intérieur de cette méthode, des instances d'autres classes sont créées, qui envoient des tâches au cloud. Le(s) résultat(s) est (sont) renvoyé(s).
Par exemple, une tâche est créée sous la forme du calcul de plusieurs coups d'échecs. Dans la méthode principale, qui est exécutée à distance, diverses combinaisons sont créées avec un compte pour un mouvement sous forme d'objets d'une certaine classe et envoyées. Ceux-ci, à leur tour, si le coup ne s'est pas terminé par un résultat ou si la profondeur de calcul n'a pas dépassé la limite, appellent à nouveau la même méthode. Et ainsi de suite.
Sans l'implication du terminal, c'est une bonne chose.
Qui produira les données pour cet "un des agents" ? Un script ou un indicateur pourra-t-il le faire ?
Chacun des agents peut générer des données brutes pour les autres. Peut envoyer par fordcast à tous ou à un agent sélectionné.
Tout agent sera en mesure d'envoyer des trames de données à tout autre agent.
Quel est le but de la communication d'agent à agent, éclairez l'ignorant si vous le pouvez.
Pour les tâches connexes où les données/résultats des calculs précédents doivent être échangés.
Il n'est pas nécessaire qu'il soit dans le nuage. Vous pouvez créer un réseau d'agents à haut débit dans votre zone locale et y exécuter une tâche complexe avec beaucoup d'échanges de données.
Par conséquent, vous pouvez construire un réseau puissant sans aucun superordinateur.
Probablement des méthodes de classe qui peuvent être appelées à distance et qui obtiennent leurs valeurs des agents. Quelque chose comme ça :
Ici, bien sûr, en même temps qu'un appel de méthode, nous devrions transmettre à l'agent les valeurs actuelles des champs de l'objet qui appelle cette méthode à distance.Non, la seule option viable et réaliste consiste à échanger des cadres de données. L'exécution à distance de fonctions n'est pas grave, car personne de sensé ne reproduirait l'environnement d'information.
Dans le cadre d'un travail d'encadrement, la fonctionnalité peut être étendue :
Juste au cas où, pour information :
Le coût de la latence du réseau est tel que, pour optimiser le processus global, vous devez procéder à une mise en lots explicite des résultats et transférer les données le moins souvent possible. Par exemple, si un problème mathématique se pose à grande vitesse (en quelques fractions de seconde) pour 100 000 000 de passages, il est préférable d'optimiser immédiatement le processus de manière algorithmique par portions de 1 000 à 10 000 passages et d'écrire un code de traitement par lots dont les résultats sont renvoyés par lots. Cela donnerait un avantage énorme par rapport à 100 000 000 de retours, où beaucoup de temps serait passé sur le réseau.
Pour notre part, nous apportons une aide sérieuse dans le cas de tâches à grande vitesse en regroupant la sortie en dizaines ou centaines de passages vers chaque agent et en regroupant également les réponses. Cela permet de réaliser d'énormes économies sur la transmission du réseau et de réduire au minimum la latence du réseau.
Non, la seule option viable et réaliste consiste à échanger des cadres de données. L'exécution à distance de fonctions n'est pas grave, car aucune personne saine d'esprit ne reproduirait un environnement informatique.
Toutes les tâches ne peuvent pas être regroupées, car dans certaines applications et tâches très gourmandes en ressources, le résultat peut être le seul ou ne pas être détecté du tout, et les tâches futiles sont écartées en cours de route, c'est-à-dire que les résultats manquants ne devraient même pas être renvoyés.
Alors il y a une autre façon de faire. C'est-à-dire que la tâche principale génère des tâches de son côté et en informe les agents. Les agents appellent des méthodes distantes avec des tâches, effectuent des calculs et s'ils obtiennent des résultats, ils appellent des méthodes distantes pour renvoyer les résultats.
Par exemple, la tâche : rechercher les diviseurs premiers des nombres de Fermat. Peut-être qu'il n'y aura pas de résultat du tout, ou un, ou plusieurs. Le fait est que la recherche de ces diviseurs très potentiels est une tâche très gourmande en ressources, car il faut d'abord créer un objet sous la forme d'un grand nombre (dans la tâche, vous ne pouvez spécifier que deux nombres entiers : le nombre premier et la mantisse, afin de réduire le coût du transfert d'informations). Ensuite, le nombre doit être vérifié pour savoir s'il est premier (effectuez un test simplifié, à l'aide duquel il sera révélé que le nombre est supérieur à 90% n'est pas premier). Et ensuite, si le test de simplicité est passé avec succès, dans la boucle, l'élévation au carré modulo cherche une correspondance. Si la condition avant la fin de la boucle ne coïncide pas, alors il n'y aura pas de résultat et il n'y aura rien à retourner. Dans ce cas, l'agent doit demander à distance le travail suivant en appelant à distance la méthode appropriée depuis l'application hôte. Si elle trouve le résultat, elle doit appeler une autre méthode et transmettre le même résultat.
C'est-à-dire que les tâches sont différentes et que les structures d'encadrement ne sont pas adaptées à toutes. Et le coût de la latence du réseau dans l'exemple ci-dessus est également négligeable, puisqu'une tâche consiste à transmettre deux entiers à un agent.
Toutes les tâches ne peuvent pas être regroupées, car dans certaines applications et tâches très gourmandes en ressources, il se peut qu'il n'y ait qu'un seul résultat ou aucun résultat du tout. Les tâches non concluantes sont écartées au fur et à mesure de la progression du jeu, c'est-à-dire que les résultats manquants n'ont même pas besoin d'être renvoyés.
Si vous utilisez un schéma de trame, ne renvoyez pas de résultats vides à l'"agent serveur" ou renvoyez simplement l'indicateur "paquet calculé, pas de données".
Savez-vous comment fonctionne le mode cadre ? L'en-tête EA démarre directement dans la fenêtre du terminal et attend les réponses (trames de données) des agents distants. En d'autres termes, la partie serveur se trouve sur le graphique, reçoit des données et peut visualiser n'importe quoi.
Lisez et essayez par vous-même : https://www.mql5.com/ru/code/914
Si vous utilisez un schéma de trame, il suffit de ne pas renvoyer de résultats vides à l'"agent serveur".
Eh bien, c'est juste la base. Les principales tâches, qui nécessitent beaucoup de calculs, sont récursives. Et le cloud n'est pas prévu pour de telles tâches, car il est conçu uniquement pour la recherche complète. Dans de nombreuses tâches appliquées, nous n'utilisons pas la force brute car elle n'a aucune perspective. Les tâches récursives sont nécessaires pour la recherche en profondeur et en largeur et en profondeur avec largeur. Par exemple, la synthèse de molécules. C'est-à-dire qu'un arbre de solutions potentielles est construit au cours du jeu, chaque branche est gourmande en ressources informatiques. Mais toutes les branches ne sont pas efficaces. C'est-à-dire que la recherche s'arrête quelque part, mais en même temps, la recherche continue pour d'autres branches potentielles en profondeur ou en largeur.
La recherche complète n'est pratiquement jamais utilisée, car pour la plupart des applications, elle ne prend pas assez de temps pour trouver une solution (par exemple, le problème de l'analyse des coups d'échecs). Mais les méthodes récursives qui coupent les branches de solutions non prospectives sont très rapides, surtout dans les calculs distribués. C'est pourquoi, si vous voulez attirer les ingénieurs d'application vers le cloud, vous devez adapter le cloud à leurs tâches, au lieu de penser qu'ils vont tout quitter et essayer toutes les variantes à la suite, indépendamment de leurs perspectives. Il serait plus facile pour eux de créer leur propre réseau de calcul distribué, même s'il est moins rapide en termes de gigaflops et comporte moins d'ordinateurs, mais il est plus efficace, car il ne cherchera que dans les domaines prometteurs et trouvera la solution nécessaire beaucoup plus rapidement que le réseau en nuage. Et de nombreux langages de programmation disposent d'une boîte à outils pour cela, c'est-à-dire d'implémentations RPC toutes prêtes.
Par exemple, la même recherche de diviseurs premiers des nombres de Fermat peut être décomposée en sous-tâches. L'application principale génère les tâches. La couche suivante crée des objets et effectue un contrôle rapide de leur simplicité à partir des tâches restantes. La couche suivante recherche les conditions, c'est-à-dire si un diviseur d'un nombre de Fermat est trouvé ou non. Les emplois sont à nouveau générés à partir des chiffres trouvés. La couche suivante effectue un contrôle complet de la simplicité, et si le nombre n'est pas premier, elle génère des travaux. S'il est premier, il renvoie le résultat à l'application principale. La couche suivante factorise les diviseurs non simples des nombres de Fermat et génère à partir d'eux des tâches pour la couche précédente.
Cela crée un convoyeur, où les agents de chaque couche accomplissent leurs tâches. Il n'est pas clair si le résultat sera trouvé. Ce qui est important, c'est que les nombres sciemment sans espoir pour la recherche ultérieure de solutions sont rejetés dans le convoyeur. En d'autres termes, cela permet d'économiser beaucoup de ressources informatiques, au lieu d'essayer d'empiler des milliers d'agents sur des tâches peu prometteuses et d'essayer de les broyer.
Ce n'est que la base. Les principales tâches sont récursives et très gourmandes en ressources pour les calculs. Et le cloud n'est pas prévu pour de telles tâches, car il est conçu uniquement pour la recherche complète. Dans de nombreuses tâches appliquées, nous n'utilisons pas la force brute car elle n'a aucune perspective. Les tâches récursives sont nécessaires pour la recherche en profondeur et en largeur et en profondeur avec largeur. Par exemple, la synthèse de molécules. C'est-à-dire qu'un arbre de solutions potentielles est construit au cours du jeu, chaque branche est gourmande en ressources informatiques. Mais toutes les branches ne sont pas efficaces. C'est-à-dire que la recherche s'arrête quelque part, mais en même temps, la recherche continue pour d'autres branches potentielles en profondeur ou en largeur.
Effectuez des calculs par lots de 1 000 à 10 000 passages, et ne renvoyez que les résultats significatifs. Il s'agit d'une technique algorithmique très efficace.
J'en ai parlé plus haut.
La recherche complète n'est presque jamais utilisée, car pour la plupart des problèmes appliqués, il ne faudra pas assez de temps pour trouver une solution (par exemple, un problème d'analyse des mouvements d'un jeu d'échecs). Mais les méthodes récursives qui coupent les branches de solutions non prospectives sont très rapides, surtout dans les calculs distribués. C'est pourquoi, si vous voulez attirer les ingénieurs d'application vers le cloud, vous devez adapter le cloud à leurs tâches, au lieu de penser qu'ils vont tout quitter et essayer toutes les variantes à la suite, indépendamment de leurs perspectives. Il leur sera plus facile de créer leur propre réseau de calcul distribué, même s'il est moins rapide en termes de gigaflops et comporte moins d'ordinateurs, mais il sera plus efficace, car il ne cherchera que dans les directions prometteuses et trouvera la solution nécessaire beaucoup plus rapidement que le réseau en nuage. Et de nombreux langages de programmation disposent d'une boîte à outils pour cela, c'est-à-dire d'implémentations prêtes à l'emploi de RPC.
Par exemple, la même recherche de diviseurs premiers des nombres de Fermat peut être décomposée en sous-tâches. L'application principale génère les tâches. La couche suivante crée des objets et effectue un contrôle rapide de leur simplicité à partir des tâches restantes. La couche suivante recherche les conditions, c'est-à-dire si un diviseur d'un nombre de Fermat est trouvé ou non. Les tâches sont à nouveau formées à partir des numéros trouvés. La couche suivante effectue un contrôle complet de la simplicité, et si le nombre n'est pas premier, elle génère des travaux. S'il est premier, il renvoie le résultat à l'application principale. La couche suivante factorise les diviseurs non premiers des nombres de Fermat et génère des tâches pour la couche précédente.
Lisez plus haut ce qui concerne l'échange de données et la démo :
Une autre extension de l'échange de données est proposée, de sorte que le processus maître puisse également transmettre des données personnalisées supplémentaires à tout agent. Il est donc possible de procéder à une lecture partielle, en distribuant de nouvelles conditions personnalisées aux agents distants. Par conséquent, il peut lire comme il veut, en changeant les conditions à chaque fois.
Une autre extension possible, lorsque les agents peuvent non seulement recevoir des tâches du maître mais aussi échanger des données entre eux. Vous pouvez bien sûr le faire par le biais de l'assistant (qui peut être très lent s'il y a beaucoup de données), mais il est encore plus efficace et plus rapide de le faire directement par les serveurs en nuage.
Renat:
Une autre extension possible consiste à permettre aux agents non seulement de recevoir des tâches de l'assistant, mais aussi de transférer des données entre eux. Vous pouvez bien sûr le faire par le biais de l'assistant (qui peut être très lent s'il y a beaucoup de données), mais il est encore plus efficace et plus rapide de le faire directement par le biais des serveurs en nuage.
C'est ce dont nous avons besoin, c'est-à-dire un transfert de données récursif d'un agent à l'autre sans assistant, mais avec un retour garanti des résultats au maître. Ainsi, l'agent ne pourrait pas prendre une tâche et arrêter de travailler sans la terminer, par exemple parce que l'ordinateur a été éteint et que la branche potentiellement efficace de la solution a été interrompue.
C'est-à-dire, par exemple, la tâche d'analyser une partie d'échecs. L'assistant dispose les pièces et génère des affectations pour la couleur des pièces qui doivent être déplacées maintenant, c'est-à-dire une pièce - une affectation. Chaque agent, après avoir reçu une tâche pour sa pièce, écarte les variantes non prometteuses pour une analyse ultérieure, lorsqu'une pièce ne peut pas se déplacer, et forme de nouvelles formations qui sont transmises comme tâches pour les pièces ennemies. Et ainsi de suite, jusqu'à ce qu'il y ait matage ou impasse ou que la profondeur de recherche soit dépassée.
Si cette tâche est confiée à la mise en œuvre actuelle du cloud, vous ne pouvez que générer des paquets de tâches pour la recherche complète. Et le nuage n'a pas assez d'agents pour cela, et il est peu probable que l'assistant ait assez de mémoire pour traiter tous ces travaux. Parce qu'il n'existe aucun mécanisme permettant d'éliminer les variantes non prometteuses. En effet, à chaque nouveau déplacement analysé des pièces, le nombre de tâches croît de manière exponentielle, mais une partie considérable d'entre elles est également rejetée et ne génère pas de tâches sans intérêt, comme dans la surcharge complète. Et on ne peut le découvrir en perspective qu'après avoir plongé à une certaine profondeur ou largeur de l'arbre de décision. Et la profondeur dans cette mise en œuvre du nuage est de 1, c'est-à-dire du maître à l'agent et inversement.
Mon point de vue est le suivant. Pour le commerce, la mise en œuvre d'une recherche récursive avec élimination des impasses est également nécessaire. Il est préférable de ne pas chercher un seul extremum, mais un ensemble d'extrema locaux (il y en a en effet beaucoup). Et l'espace de recherche de toutes les variantes possibles est astronomique, c'est-à-dire qu'aucun agent pris dans tous les réseaux de calcul distribué ne sera suffisant. Pour ce faire, à chaque étape, nous énumérons les plus proches voisins d'un point (coordonnées du point - paramètres d'entrée de l'EA) à une certaine distance de celui-ci et espacés d'une certaine valeur angulaire, pour voir s'ils améliorent ou non les résultats par rapport au résultat actuel. Si l'une d'entre elles est plus mauvaise ou dépasse la profondeur de recherche, nous la rejetons. S'ils s'améliorent, nous regardons récursivement plus loin et formons un ensemble de tâches supplémentaires à partir des points améliorés que nous distribuons aux agents. Si un extremum est trouvé localement (tous les points du voisinage ne font qu'empirer le résultat actuel), nous renvoyons le résultat à l'application principale. Une fois les extrema identifiés, ils sont confiés à l'assistant et analysés plus en détail à l'aide de tests prospectifs.
Une telle tâche ne peut être résolue directement, car le nombre de variantes est astronomique. Un algorithme génétique ne cherche pas non plus les extrema locaux (il s'arrête près de l'extrema global dans le voisinage immédiat également) et ne montre que les résultats intermédiaires, indépendamment de leur extremum. Cela ne veut pas dire que l'espace de recherche de l'algorithme génétique et de l'algorithme de force brute est limité et discret. Il s'agit de la recherche d'un nombre maximal d'extrema locaux, mais rapidement, c'est-à-dire en coupant les générations non prospectives de tâches du maître vers les agents et de l'agent vers d'autres agents, et avec une portée illimitée (mais de manière à ce que des restrictions puissent être fixées si nécessaire, par exemple la profondeur de recherche dans de tels algorithmes est toujours limitée). Si le nuage mettait en œuvre le transfert récursif des tâches, le problème serait résolu.