Mon approche. Le noyau est le moteur. - page 146
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
Реter Konow:
...
Ce n'est pas une mauvaise idée.
Mais, qu'est-ce que ça nous apporte ?
Peut-être que nous réduisons la charge du processeur, libérons des fils. Si nous avons 10 copies d'EA fonctionnant sur 10 paires, et que nous chargeons chaque moteur avec une interface graphique, la charge totale du CPU peut être trop élevée. En effet, chaque interface graphique nécessite de redessiner les éléments, ce qui représente une charge importante pour le processeur. Mais en fait, nous ne pouvons voir qu'une seule interface graphique concrète d'une copie. Les autres sont cachés.
Donc c'est probablement la bonne façon de faire. Faire un moteur commun.
Dans MT5, les graphiques peuvent être détachés. Et il faut alors recommencer le concept.
Chaque EA possède sa propre copie du noyau de paramètres. Il peut être temporairement déconnecté de l'interface graphique commune et un autre EA peut être connecté au moteur. Il est important qu'il s'agisse de copies de la même EE.
Toutefois, il existe certaines difficultés, que je n'ai pas encore pleinement comprises.
En théorie, la question ressemble à ceci :
Pourquoi avons-nous besoin d'ajouter un moteur avec une interface graphique pour chaque graphique d'une copie de l'EA si nous pouvons faire un moteur avec l'interface graphique commune et le connecter à toutes les copies de l'EA ?
En pratique, nous rencontrerons quelques difficultés techniques.
La copie du conseiller expert peut écrire de nouvelles valeurs dans sa copie du noyau de paramètres. Si l'une des copies n'est pas connectée au moteur, le noyau ne changera que du côté de la copie. Ainsi, lors de la reconnexion, nous devons passer le noyau entier au moteur et le moteur redessinera tous les éléments dans toutes les fenêtres où cela est nécessaire. Cela est possible en principe.
Ou refaire le noyau des paramètres lui-même en en faisant une ressource. Dans ce cas, le moteur recevra tous les changements en même temps et redessinera simplement les éléments. Ce n'est pas une mauvaise idée.
Mais, qu'est-ce que ça nous apporte ?
Nous pouvons peut-être réduire la charge du processeur et libérer des fils. Si nous avons 10 copies d'EA fonctionnant sur 10 paires et que nous chargeons chaque moteur avec une interface graphique, la charge totale du CPU peut être trop importante. En effet, chaque interface graphique nécessite de redessiner les éléments, ce qui représente une charge importante pour le processeur. Mais en fait, nous ne pouvons voir qu'une seule interface graphique concrète d'une copie. Les autres sont cachés.
Donc c'est probablement la bonne façon de faire. Faire un moteur commun.
Laissez les copies EA communiquer leur adresse au moteur avec fréquence. Une courte chaîne. Le moteur réagira et "parlera" à la copie qui a la même adresse que sa copie actuelle. L'échange standard aura lieu. Si l'adresse change dans le moteur, il commence à "échanger" avec la copie qui définit l'adresse correspondante. L'échange standard d'"éther" ajoute des conseillers ou des indicateurs pour exposer son adresse courte. Plusieurs octets. Et la fonction "écouter les adresses du moteur" démarre lorsque l'utilisateur appuie sur le bouton "reconfigurer" de l'interface graphique du moteur. Peut-être que c'est quelque chose comme ça.
Dans MT5, vous pouvez détacher les graphiques. Et il faut alors recommencer le concept.
Je n'en suis pas conscient. La carte est détachée purement "territoriale", elle s'affranchit des coordonnées de la fenêtre principale du terminal ? Dans les flux d'échange, est-il toujours connecté au terminal dans son intégralité ?
Je n'en suis pas conscient. La carte est détachée purement "territoriale", elle s'affranchit des coordonnées de la fenêtre principale du terminal ? Et dans les flux d'échange avec le terminal, il est toujours connecté au terminal dans son intégralité ?
Le tableau est détaché, mais cela ne change pas l'essentiel. Ils font du désordre pour rien). Il est inutile de faire des copies de l'interface graphique pour chaque copie de l'EA. Pas que je puisse voir, en tout cas. Mais il serait formidable de pouvoir déplacer une interface graphique entre les cartes de copies.
S'il existe une carte du centre de contrôle de la copie d'EA sur laquelle se trouvent le moteur et l'interface graphique principale, ce serait pratique.
L'interface graphique de l'EA doit être conçue en tenant compte du fait que l'EA aura un grand nombre de répliques configurées sur différents instruments.
SZY. Le graphique reste dans la même fenêtre, seule la fenêtre elle-même peut être "sortie" du terminal.
Que les copies des conseillers indiquent au moteur leur adresse avec fréquence. Une courte chaîne. Le moteur réagira et "parlera" à la copie qui a la même adresse que sa copie actuelle. L'échange standard aura lieu. Si l'adresse change dans le moteur, il commence à "échanger" avec la copie qui définit l'adresse correspondante. L'échange standard d'"éther" ajoute des conseillers ou des indicateurs pour exposer son adresse courte. Plusieurs octets. Et la fonction "écouter les adresses du moteur" démarre lorsque l'utilisateur appuie sur le bouton "reconfigurer" de l'interface graphique du moteur. Peut-être que ça donne quelque chose comme ça.
Vous voyez l'essence correctement. Seuls les détails ne sont pas exacts.
Changer la "communication" elle-même n'est pas un problème. Mais, lors d'un changement, vous devez réinitialiser l'ensemble de l'interface graphique. Après tout, dans les fenêtres et les éléments de différentes copies, différentes valeurs. Il est donc nécessaire de redessiner presque tout.
Les valeurs des paramètres de chaque copie sont stockées dans le noyau de paramètres. Il s'agit d'un tableau. Tant que la copie est déconnectée du moteur, les changements de valeurs ne se produiront que dans la copie du noyau de paramètres du conseiller expert. Dès que le moteur est connecté, tout doit être transféré vers lui à partir de ce noyau. Synchroniser les copies du noyau de paramètres dans le moteur et le conseiller expert connecté. Vous devez donc transférer une grande quantité d'informations (Parameter Core), et redessiner les fenêtres. Après cela, il sera possible d'ajuster le conseiller expert connecté et les autres passeront en mode indépendant. Ensuite, une connexion sera établie avec eux et la même chose se produira.
Ce sera comme ça. Cependant, il y a beaucoup de nuances techniques.
Peter. Avec une période de N ms, l'EA reçoit quelque chose du moteur, et après cela, il transmet au moteur ce qu'il a préparé. Le conseiller attend alors l'arrivée de la tique ou un nouveau lot d'interrogatoire-échange. N'est-ce pas ?
C'est presque ça. La communication et l'anticipation des tics, ou d'autres événements, se font de manière asynchrone.
L'horaire est détaché, mais cela ne change rien à l'affaire. C'est une perte de temps).
...
SZY. Le graphique reste dans la même fenêtre, seule la fenêtre elle-même peut être "sortie" du terminal.
Et selon votre conception selon laquelle un seul graphique actuel est visible à la fois de toute façon, et seul celui-ci peut être mis à jour, sera brisé - il y aura autant de graphiques visibles qu'ils sont détachés.
Ce n'est certainement pas un cauchemar, mais ce n'est pas bon non plus - seul un des graphiques visibles sera "vivant", et le reste ?
Pensez-vous que c'est normal ? Eh bien si c'est le cas, une fois de plus je suis convaincu du manque de sérieux dans la résolution des bugs - s'il y en a un, ce n'est pas de le corriger, mais de le cacher.
C'est presque ça. La communication et l'attente d'un tick, ou d'autres événements, se font de manière asynchrone.
Que dites-vous de ça ? Les conseillers, chacun avec une certaine fréquence (OnTimer), envoient au moteur sa chaîne de code. Toutes les lignes de code sont différentes. Le moteur analyse en interne les chaînes entrantes et en "reconnaît" une, par exemple celle du conseiller expert numéro 3. En réponse à cette EA, il envoie un "signal" pour lancer la transmission principale. Le moteur fonctionne avec ce conseiller expert.
Si une personne appuie sur le bouton "Switch", le moteur analyse les conseillers autorisés, et ils sont indexés, sous des numéros. Indique à l'EA actuel de passer à l'état de définition d'une adresse, comme s'il était désactivé du flux de travail, choisit la chaîne de code avec l'indice par 1 de plus et attend l'arrivée de la même chaîne de code de n'importe quel autre EA. Lorsque l'adresse correspond, il envoie un signal au conseiller expert pour qu'il cesse d'exposer l'adresse et commence l'échange. Le seul Expert Advisor et la seule série de copies, qui n'est pas en mode de facturation, recevront l'échange. En bref, quelque chose comme.
Si le moteur reçoit une adresse, il effectue un timeout pour interdire la réception d'adresses. Pour que les adresses ne se chevauchent pas.
Que dites-vous de ça ? Les conseillers experts, chacun avec une fréquence quelconque (OnTimer), envoient au moteur leur propre chaîne de code. Toutes les lignes de code sont différentes. Le moteur analyse en interne les chaînes entrantes et en "reconnaît" une, par exemple celle du conseiller expert numéro 3. En réponse à cette EA, il envoie un "signal" pour lancer la transmission principale. Le moteur fonctionne avec ce conseiller expert.
Si une personne appuie sur le bouton "Switch", le moteur analyse les conseillers autorisés, et ils sont indexés, sous des numéros. Indique à l'EA actuel de passer à l'état de définition d'une adresse, comme s'il s'agissait d'un arrêt du flux de travail, il sélectionne une chaîne de code avec l'indice par 1 de plus et attend l'arrivée de la même chaîne de code de n'importe quel autre EA. Lorsque l'adresse correspond, il envoie un signal à ce conseiller expert pour qu'il cesse d'exposer l'adresse et commence l'échange. Le seul Expert Advisor et la seule série de copies, qui n'est pas en mode de facturation, recevront l'échange. En bref, quelque chose comme.
Si le moteur reçoit une adresse, le temps d'inhibition de l'adresse est écoulé. Pour que les adresses ne se chevauchent pas.
Ce n'est pas la bonne approche. Laissez-moi vous expliquer :
Chaque copie d'EA ne cesse d'écrire ses messages au moteur dans sa propre ressource séparée. En même temps, chaque copie de l'EA initialise les valeurs de ses propres éléments dans sa copie des paramètres du noyau. Autrement dit, même lorsqu'elles sont déconnectées du moteur, toutes les copies de l'EA doivent fonctionner correctement.
Lorsque le moteur change de connexion entre les copies de l'EA, il doit synchroniser les paramètres de son noyau avec le noyau de l'EA connectée. Ensuite, redessinez les éléments dans les fenêtres, afin qu'ils affichent les informations réelles.
Quant à la communication avec le conseiller expert sélectionné, tout est simple. La ressource pour recevoir les messages du moteur (ainsi que la ressource des messages pour le moteur), chaque EA aura la sienne. Autrement dit, le moteur se contentera d'enregistrer ses messages dans l'autre ressource et de lire les messages de cette dernière. Cette ressource appartient à l'EA connectée.