Testeur soutenant les scripts et les conseillers MG4 - page 10
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
Je n'ai pas dit ça.
Je n'ai pas du tout abordé ce sujet et je n'ai pas l'intention de m'en mêler.
Apparemment, il me semblait :
Et les stoplots et takeprofits intégrés sont en fait virtuels et sont lancés pour être exécutés sur le marché le moment venu. Cette solution a un bon côté - elle permet d'économiser sur le CS (collatéral, marge).
Réfléchissez à ce qu'apportent les nouvelles fonctionnalités d'accès aux données et pourquoi c'est le cas.
MetaTrader 4 dispose d'une profondeur d'historique limitée, d'horizons temporels distincts et d'un accès direct aux barres de son symbole via Open/High/Low/Close/Time[xxx]. Un tel accès direct est très coûteux à mettre en œuvre en termes de ressources et de coût de l'unité centrale. Considérez que chaque conseiller expert a sa propre copie locale de ces données pour éviter les conflits avec les autres conseillers experts et le terminal lui-même.
Lorsque le nombre de symboles augmente (par exemple, dans MT5, vous pouvez avoir 5 000 à 10 000 instruments), et en utilisant l'historique en minutes profondes comme base de toutes les échéances, il n'est plus possible en principe d'utiliser les méthodes de MT4. Il n'y a pas assez de RAM, et la copie de gros morceaux nuit aux performances. C'est pourquoi MT5 ne maintient plus automatiquement une copie cachée et coûteuse du graphique pour chaque expert.
Au lieu de cela, nous sommes passés à des fonctions CopyXXX très économiques où le développeur demande exactement au tableau local la quantité de données dont il a besoin, et non la totalité du graphique disponible. Ensuite, il y a le traitement le plus rapide possible des données locales (au lieu de l'ancien système plutôt coûteux Open/High/Low/Close/Time[xxx]), et l'auteur peut mettre ces données en cache et les utiliser avec parcimonie lors du prochain appel. Les économies de mémoire et de CPU sont énormes. En outre, la plate-forme elle-même est particulièrement libre de gérer de vastes bases de données - l'accès à celles-ci se fait toujours à la demande (plutôt que par un accès direct non supervisé), ce qui permet une gestion souple des caches.
Il convient également de noter que la simplicité des appels Open/High/Low/Close/Time[xxx] dans MQL4 était limitée au symbole et à la période en cours, et que toutes les autres données pour les autres symboles et périodes étaient obtenues à l'aide des fonctions iClose/iLow(...), ce qui entraînait de sérieux retards. La transition dans MQL5 vers un modèle de fonction unique CopyXXX a radicalement amélioré la situation, permettant aux développeurs d'obtenir les blocs de données requis en une seule requête, et de ne pas faire de multiples appels bloqués (pensez à tous les blocages dans chaque appel unique à iClose).
...
Et les performances de CopyXXX ?
En termes d'économie de mémoire - pas de questions. Mais il est plus coûteux d'appeler CopyXXX pour chaque tick que de copier une fois un tableau de cotations dans un tampon et d'y accéder par un index direct de type Rates[X]. Nous nous trouvons face à un dilemme classique de la programmation : "Économiser la mémoire ou économiser le temps du processeur".
Pas moins qu'un MT5. Maintenant, posez la même question à vous-même, mais en remplaçant un B par un A.
Allez apprendre ce qu'est le MARCHÉ ! Trader, vous savez....
Vous dites donc que MT4 peut, disons, stocker l'historique des spreads ou "connaître" les volumes réels (sans toutes les béquilles et autres solutions totalement inadéquates) ?
Êtes-vous d'accord pour dire que sur le marché réel, l'écart n'est clairement pas fixe ? Allez-y et dans le testeur MT4, essayez de tester l'EA sur des cotations avec un écart variable, puis nous parlerons.
Je ne me soucie pas tant du reste du monde que des intérêts du développement des experts aux logiques complexes. ;)
La solution de compromis serait d'organiser les ordres virtuels au niveau de MT5. Il y aurait alors à la fois le filet dont quelqu'un a besoin et la vieille logique du travail avec les commandes.
Prendriez-vous les risques d'une telle "visualisation" ?
Dans MT5, tous ceux qui le souhaitaient ont longtemps utilisé la solution en se couvrant avec des trades sur différents instruments ayant un haut degré de corrélation.
Oui, cela peut nécessiter beaucoup plus de marge que dans MT4, mais le bon sens le dit.
Bien entendu, personne n'a annulé le régime "virtuel" dans ce cas.
Donc, vous dites que MT4 peut, disons, stocker l'historique des spreads ou "connaître" les volumes réels (sans toutes les béquilles et autres solutions inadéquates) ?
Êtes-vous d'accord pour dire que sur le marché réel, l'écart n'est clairement pas fixe ? Allez-y et dans le testeur MT4, essayez de tester l'EA sur des cotations avec des spreads changeants, puis nous parlerons.
Vous allez prendre les risques d'une telle "visualisation" ?
Dans MT5, tous ceux qui le souhaitent utilisent une solution de couverture en utilisant des transactions dans différents instruments avec un haut degré de corrélation.
Dieu merci, il y a MT4 pour le moment. :) Vous pouvez l'utiliser sur un seul instrument si vous le souhaitez. Vous pouvez utiliser différents instruments.
Quels sont, selon vous, les risques ?
Qu'en est-il des performances de CopyXXX ?
En termes d'économie de mémoire - pas de questions. Mais il est plus coûteux d'appeler CopyXXX pour chaque tick que de copier une fois un tableau de cotations dans un tampon et d'y accéder par un index direct de type Rates[X]. Nous nous trouvons face à un dilemme classique de la programmation : "Économiser la mémoire ou économiser le temps du processeur".
CopyXXX a la même vitesse que les fonctions iClose/iOpen/iXXXX. Seul iXXX renvoie un élément à la fois, tandis que CopyXXX en renvoie plusieurs et est donc plus efficace et plus rapide.
Probablement, vous ne considérez pas que MT4 copie de force _tout_ l'historique du graphique local dans l'environnement de marché de l'EA local (cache) avant le démarrage de chaque tick handler. Et cela coûte très cher, bien que nous disposions d'une méthode de mise à jour économique de ces informations. La fonction spéciale RefreshRates de MQL4 provoque un rafraîchissement forcé des caches et de l'historique de la carte locale.
L'appel à CopyXXX est beaucoup plus efficace, et les développeurs disposent d'un mécanisme très précis et exact de mise en cache des données précédemment demandées. Par exemple, vous n'avez pas besoin de redemander l'historique profond à chaque tic, mais de le stocker/écrire localement et d'y accéder aussi rapidement que possible.
Si nous comparons les anciennes méthodes d'accès "direct" (qui n'est en fait pas un accès direct) Open/High/Low/Close et le travail avec le tableau local double local[xxxx], ce dernier est plusieurs fois plus rapide. Par conséquent, il est préférable de faire une copie sur soi en local et de disposer ainsi d'un accès local rapide aux données interrogées à plusieurs reprises.
Dieu merci, il y a un MT4 pour le moment. :) Avec elle, vous pouvez utiliser un seul instrument à la fois. Vous pouvez utiliser différents instruments.
Quels sont, selon vous, les risques ?
Le développement et l'utilisation de "plateformes commerciales" entraînent certains coûts et risques, que quelqu'un finit par assumer.
En ce qui concerne la "virtualisation" dans les logiciels d'autres développeurs
C'est une bonne chose, à condition que tout soit utilisé pour lui-même et que les personnes qui mettent en œuvre la solution comprennent ce qu'elles font.
Les principaux coûts seront les suivants : l'argent dépensé pour développer le système, l'argent dépensé pour le faire fonctionner et le temps consacré à la mise en œuvre du projet.
Les principaux risques : trop de temps ou d'argent seront dépensés pour mettre en œuvre un projet viable (le projet ne sera pas rentable), le projet ne sera pas efficace par rapport à d'autres solutions, des erreurs cachées dans le code ou les algorithmes seront introduites pendant la mise en œuvre du projet.
Oui, les banques et autres acteurs du marché ont recours au développement de leur propre logiciel avec les fonctionnalités nécessaires, mais ils y consacrent énormément de temps et de ressources. En attendant, ils assument absolument tous les risques.
Concernant le travail avec MT5 (différentes variantes utilisant MT5)
Ici, bien sûr, MQ a fait le plus gros du travail, mais a également introduit certaines restrictions sur la fonctionnalité.
Les principaux coûts seront : l'argent dépensé pour maintenir les performances du système et le temps consacré au projet.
Les principaux risques : le projet ne sera pas efficace par rapport à d'autres solutions, il y aura des erreurs cachées dans le code ou les algorithmes lors de la mise en œuvre du projet, vous devrez surveiller en permanence les performances de l'ensemble du système (le protéger des problèmes logiciels et matériels ; surveiller la qualité des communications, l'alimentation électrique, la sécurité des données, etc.)
Vous pouvez bien sûr envisager une application commerciale (permettant à d'autres personnes de l'utiliser), avec certaines limitations et réserves.J'aimerais jeter un coup d'oeil à
Voici un exemple où la simplicité et la facilité d'utilisation de la POO lors de l'écriture de programmes simples sont particulièrement évidentes.