Résultats du test expert multi-devises - page 5
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
De quelle réalité parlez-vous ? Des tests en temps réel ? Si c'est le cas, alors je suis d'accord, bien sûr. Si vous accrochez deux EA à vos symboles, tout sera correct. Mais je suis en train de tester le mode multi-devises. Et un résultat identique est montré en utilisant uniquement OnTimer() (10 secondes).
Je parle d'une exécution réelle en mode multidevise (négociation sur N symboles dans des EA (dans chaque EA) définis pour chacun des symboles) - cela donne une estimation réelle, alors que dans le cas du testeur, vous comparez principalement les modes de test, et non l'exactitude de chacune des méthodes de traitement des tick multidevise. Quel est l'intérêt de comparer différents modes s'ils sont tous basés sur l'environnement artificiel du testeur ? L'identité des résultats des runs ne permet pas de prétendre qu'il donne les résultats les plus corrects en termes de trading, il est l'optimum en termes de fonctionnement interne du testeur.
Commençons par la formulation correcte. Dans l'exemple original, vous auriez voulu "négocier en eurodollars". En fait, les événements personnalisés provenaient de deux symboles et dans le gestionnaire d'événements, TradeSignalCounter()+TradePerformer() étaient appelés lorsque des événements provenant de l'un de ces deux symboles étaient reçus. Nous pouvons supposer que la file d'attente des événements était toujours pleine.
Maintenant, vous avez supprimé l'une des sources de signaux, mais vous avez introduit la vérification"if(sparam == Symbol_01)" dans le gestionnaire d'événements pour une raison quelconque. Mais la question suivante est différente. A en juger par le code, le schéma de Lizar est utilisé en mode "All ticks" et les fonctions TradeSignalCounter()+TradePerformer() sont appelées à chaque tick depuis la source du signal (EURUSD). Intéressant a déjà fait allusion à un possible débordement de la file d'attente des événements. Mais je veux savoir quel instrument est utilisé comme paramètre Symbol_01 de ces deux fonctions, et si vous avez essayé de changer la périodicité des événements dans le schéma de Lizar.
Oui, c'est ce que je voulais faire. Après tout, chaque action que nous entreprenons est déclenchée par notre désir. Dans ce cas, j'ai eu exactement ce que je voulais. C'est-à-dire que nous n'avons négocié que sur l'EURUSD, car la fonction TradePerformer() vérifie si elle est autorisée à négocier pour chaque symbole du tableau de symboles. Cette option est située dans des variables externes et à cette époque, le trading utilisant le symboleGBPUSD était interdit. Les événements utilisateur provenaient de deux symboles, mais dans le gestionnaire d'événements, là encore, la fonction TradePerformer() n'autorisait la négociation que sur le symbole EURUSD. La fonctionTradePerformer() contient également une fonction qui détermine si une nouvelle barre s'est produite sur un symbole particulier, dans ce cas EURUSD. Votre hypothèse selon laquelle la file d'attente des événements a toujours été pleine est correcte, mais dans ce cas, tout a été traité séparément et un retard d'un tick n'est pas significatif lorsque vous effectuez des tests sur des barres quotidiennes.
Le fait de retirer une source de signal, celle qui ne devait pas être impliquée dans les tests, n'a fait que confirmer que tout avait été fait correctement auparavant. Le contrôle"if(sparam == Symbol_01)" est resté à partir du moment où j'ai vérifié les résultats sans supprimer la source de signal sur laquelle le test ne devrait pas avoir lieu, mais à partir de laquelle il devrait avoir lieu. Cette vérification s'est avérée en fait même superflue. Les résultats n'ont pas changé. Le symbole EURUSD est utilisé comme paramètre Symbol_01. J'ai essayé de modifier la fréquence des événements mais cela n'a rien changé. Plus précisément, je peux dire que le mode "tous les ticks" est le plus précis.
Je parle d'une exécution réelle en mode multidevises (négociation sur N symboles dans des EA (dans chaque EA) définies pour chacun des symboles) - cela donne une estimation réelle, et dans le cas du testeur, vous comparez principalement les modes de test, et non l'exactitude de chacune des méthodes de traitement des tick multidevises. Quel est l'intérêt de comparer différents modes s'ils sont tous basés sur l'environnement artificiel du testeur ? Les résultats identiques des runs ne nous permettent pas d'affirmer qu'il donne les résultats les plus corrects du point de vue du trading, il est l'optimum du point de vue des mécanismes internes du testeur.
Maintenant je comprends. Mais la discussion portait à l'origine sur les tests dans le testeur. Avant de commencer à négocier, vous devez tester le système. Plus le test est précis, plus vous vous sentirez en confiance dans le trading réel. Les résultats des tests présentés ici montrent que les tests peuvent être bien et mal faits. Désormais, chacun a le choix et peut décider lui-même de ce qui est bien ou mal. Un trader a dit à juste titre (si je ne me trompe pas, il s'agit de Van Tharp) : "Nous faisons du commerce avec nos perceptions". Je peux ajouter à cela. Nous n'échangeons pas seulement nos idées. Nous vivons même selon nos perceptions. ))
Si nous attachons un conseiller expert séparément à chaque symbole dans le trading réel ou les tests, il sera le plus précis. Bien sûr, je suis d'accord avec ça. Mais il n'y a pas besoin de synchronisation des barres pour cela. La précision s'accompagne de la durée. Dans le testeur, vous pouvez évaluer de longues périodes historiques. Et je préfère personnellement voir les résultats corrects des tests.
Je tiens également à souligner un autre point : je n'exclus jamais la possibilité de me tromper quelque part et je vérifie toujours tout. Mais même après les tests les plus difficiles, lorsque tout semble correct à première vue, je n'exclus toujours pas la possibilité qu'il y ait une erreur quelque part. À ce stade, si quelqu'un n'est pas d'accord avec l'évaluation des résultats de ces méthodes d'essai qui sont présentées, il doit fournir ses propres résultats d'essai en comparaison. Après tout, le but de ce fil de discussion est de savoir comment faire ce qu'il faut ou, pour être plus précis, comment tester correctement les Expert Advisors multidevises, et non de savoir qui a raison ou tort en paroles. Les faits, seulement les faits et rien que les faits ! )))
Quel est l'intérêt de comparer différents modes s'ils sont tous basés sur un environnement de test artificiel ?
Il s'agit de prendre une décision correcte sur la base des résultats. Et je ne vois certainement pas l'intérêt d'analyser des données déformées. Après tout, on récolte ce que l'on sème).
Le fait de retirer une source de signal, celle qui ne devait pas être impliquée dans le test, n'a fait que confirmer que tout avait été fait correctement auparavant.
"...cela a été fait correctement avant" est de la catégorie de la complaisance. C'était mal pour commencer. Vous ne semblez pas accorder d'importance à un phénomène tel que "l'encombrement des files d'attente pour les événements". En particulier lorsqu'il s'agit de la transmission post-it des événements. Jetez un coup d'œil aux documents de référence et au forum sur le sujet. Le mot clé est "file d'attente".
... Je n'ai négocié que sur l'EURUSD car la fonction TradePerformer() vérifie si elle est autorisée à négocier pour chaque symbole du tableau de symboles. Cette option est située dans les variables externes, et à cette époque, le trading sur le symboleGBPUSD était interdit. Les événements utilisateur provenaient de deux symboles, mais dans le gestionnaire d'événements, là encore, la fonction TradePerformer() n'autorisait la négociation que sur le symbole EURUSD. La fonction TradePerformer() contient également une fonction qui détermine si une nouvelle barre s'est produite sur un symbole particulier, dans ce cas EURUSD. Votre hypothèse selon laquelle la file d'attente des événements a toujours été pleine est correcte, mais dans ce cas, tout a été traité séparément et un retard d'un tick n'est pas significatif lorsque l'on teste sur des barres quotidiennes.
Puisque TradeSignalCounter()+TradePerformer() ont traité les événements d'une seule source de signaux, l'état de la file d'attente et son éventuel dépassement n'ont pas changé du tout. En d'autres termes, l'"interdiction de traiter les événements par symbole GBRUSD" n'a pas du tout supprimé les événements appropriés de la file d'attente. Pour la troisième fois, je signale le problème : "Un éventuel débordement de la file d'attente des événements a déjà été évoqué" :) Si vous pensez qu'il ne s'agit que d'"un tic-tac de retard", sur quoi se fondent ces conclusions ?
"...Dans ce cas, tout a été traité séparément". Le problème est que dans la version originale, le gestionnaire d'événements appelait des fonctions lorsque des événements étaient reçus des deux sources de signaux, et ces fonctions filtraient déjà le signal de la source "inutile". Mais les fonctions ont été appelées à chaque ( !) fois.
Un retard d'un tick n'est pas significatif lorsqu'il est testé sur des barres quotidiennes.
La période à laquelle le gestionnaire d'événement est testé n'a pas d'importance. Si le système de Lizar génère des signaux par tic-tac, alors ils notent la file d'attente des événements par tic-tac également, et non une fois par jour.
"J'ai essayé de changer la fréquence des événements, mais cela n'a pas fait de différence. Plus précisément, je peux dire que le mode "tous les tics" est le plus précis." Pourriez-vous fournir des captures d'écran comparatives sur les modes non-tick de Lizar ?
Si vous mettez un EA sur chaque symbole séparément en trading réel ou en test, ce serait l'option la plus précise. Bien sûr, je suis d'accord avec ça. Mais il n'est pas nécessaire de synchroniser les barres. La précision s'accompagne de la durée. Vous pouvez estimer de longues périodes historiques dans le testeur. Et je préfère personnellement voir les résultats corrects des tests.
Il s'agit de prendre une décision correcte sur la base des résultats. Mais je ne vois absolument pas l'intérêt d'analyser des données corrompues. Après tout, on récolte ce que l'on sème).
Ce que j'essaie de souligner, c'est que la catégorie de la "justesse" a maintenant été remplacée par l'identité des parcours des testeurs, mais cela ne signifie pas que ces données sont moins déformées. En particulier, vous avez maintenant choisi un intervalle de 10 secondes, qui est sans aucun doute plus déformant que, par exemple, un intervalle de 5 secondes ou de 1 seconde. En d'autres termes, vous exploitez une caractéristique des conditions de fonctionnement du testeur qui vous donne la méthode préférée avec la minuterie de 10 secondes. En fait, vous essayez d'"attraper" le moment de l'arrivée des ticks des nouvelles barres sur tous les instruments avec des événements timer, et il est assez évident que la meilleure façon de le faire est avec l'événement OnTick.
Ne perdez pas votre temps. Vous n'obtiendrez jamais une correspondance parfaite sur les tiques. Le temps de fermeture d'une mesure est différent selon les instruments.
Pour un instrument, l'heure actuelle est l'heure de clôture de la barre, pour un autre, la barre n'a pas encore été formée, et pour le troisième, elle a été formée il y a plusieurs ticks.
Regardez l'historique des ticks, le volume des ticks diffère souvent d'un instrument à l'autre.
Yedelkin 2011.08.25 08:16 #
"...tout a été fait correctement avant" est de la catégorie de la complaisance.
---
Bonjour ! ))
Outre cette phrase arrachée séparément, j'ai également écrit : ".Je n'exclus jamais de me tromper quelque part et je vérifie toujours tout. Mais même après les contrôles les plus rigoureux, lorsque tout semble correct à première vue, je ne peux toujours pas exclure la possibilité qu'il y ait une erreur quelque part". Je dois ajouter que je ne suis pas le genre de personne qui pense avoir toujours raison sur tout. )))
---
Yedelkin :
C'était faux à l'origine. Apparemment, vous n'attachez pas d'importance à un phénomène tel que "l'encombrement des files d'attente pour les événements". En particulier lorsqu'il s'agit de la transmission post-it des événements. Jetez un coup d'œil aux documents de référence et au forum sur le sujet. Le mot clé est "file d'attente".
---
J'ai jeté un coup d'œil à la rubrique Timer. Les points clés que j'ai soulignés sont les suivants :
1. Pendant qu'un événement est en cours de traitement, les autres peuvent ne pas être traités.
2. Si la pile d'événements déborde, les anciens événements sont retirés de la file d'attente sans être traités.
Prenons les choses dans l'ordre. Il existe une énumération d'événements :
Lors de l'initialisation, précisez à partir de quel symbole nous accepterons l'événement et quel événement nous accepterons :
Autrement dit, nous n'accepterons l'événement CHARTEVENT_TICK que pour le symbole EURUSD. Il n'y a pas d'autres symboles.
Le test a commencé. Lorsqu'un événement se produit, le programme entre dans la fonction OnChartEvent(), déclare des tableaux de variables pour les signaux de trading et vérifie l'événement. S'il s'agit d'un événement personnalisé, le programme détermine le signal dans TradeSignalCounter(), puis il vérifie si une nouvelle barre s'est produite dans la fonction TradePerformer() et décide ensuite d'autres conditions en fonction de cela. La fonction termine son travail et ne le reprend que lorsqu'un événement se produit sur le graphique EURUSD. En d'autres termes, une coche dans ce cas.
Yedelkin :
Du fait que TradeSignalCounter()+TradePerformer() ont traité les événements provenant d'une seule source de signaux, l'état de la file d'attente des événements et son éventuel débordement n'ont en rien changé. En d'autres termes, l'"interdiction de traiter les événements par symbole GBRUSD" n'a pas du tout supprimé les événements appropriés de la file d'attente. Pour la troisième fois, j'attire l'attention sur le problème : "Un débordement possible de la file d'attente des événements a déjà été signalé par Intérêt" :) Si vous pensez qu'il ne s'agit que d'"un tic-tac de retard", sur quoi se fondent ces conclusions ?
---
L'exécution des fonctions énumérées est très rapide. La file d'attente des événements ne déborde pas et aucun événement important n'est manqué. Et si la file d'attente déborde même et que des événements sont manqués, que manquerons-nous ? Un tic, deux tics, trois ? Et alors ? C'est insignifiant sur les barres de jour.
---
Yedelkin :
Le problème est que dans la version originale, le gestionnaire d'événements appelait des fonctions lorsque les événements provenaient des deux sources de signaux, et ces fonctions filtraient déjà le signal provenant de la source "inutile". Mais les fonctions ont été appelées à chaque ( !) fois.
---
Pourquoi vous accrochez-vous à cette deuxième source ?)) Il n'y a plus de deuxième source. Il n'y en a qu'un - EURUSD, mais le conseiller expert passe du graphique GBPUSD à EURUSD. Et les résultats sont identiquement faux. Une copie. C'est-à-dire qu'ils sont les mêmes que si la deuxième source était présente. )))
-----------
Il est préférable de faire le test vous-même, de montrer les résultats du test et d'écrire (brièvement) ce que vous avez fait pour obtenir les bons résultats du test, si bien sûr vous y parvenez. L'expert le plus simple fera l'affaire pour ce test. Entrée par n'importe quelle condition, Stop Loss, Take Profit. Soit les barres quotidiennes des 10 dernières années. Et vous verrez par vous-même. Certaines périodes coïncideront, d'autres non. Ouvrez le tableau des résultats pour voir où se trouve la discordance.
Comment se fait-il que vous n'ayez pas besoin de faire la synchronisation des barres en ligne !
Parce que vous avez écrit avant ça :
marketeur:
Je parle d'un run réel en mode multidevises (trading sur N symboles dans des EA (dans chaque EA) paramétrés sur chacun des symboles) - cela donne une estimation réelle...
J'en déduis que par "exécution réelle", vous entendez un test en ligne, lorsque plusieurs EA sont en cours d'exécution et que chacun d'eux survole directement son propre symbole. Si c'est ce que vous vouliez dire, alors une question. Pourquoi avons-nous besoin de la synchronisation des barres dans ce cas, si chaque Expert Advisor est situé sur son propre symbole ? La synchronisation des barres dans ce cas est peut-être nécessaire si le système de trading est organisé de telle manière qu'une décision est prise sur plusieurs symboles à la fois, de sorte que des barres sur ces plusieurs symboles doivent être formées. Je veux dire trader indépendamment sur plusieurs symboles tout en étant sur un symbole (sur n'importe quel symbole).
Marketeer:
Toutes ces expériences dans le testeur sont nécessaires pour estimer le trading en ligne, et la question de ce sujet ne concerne pas le testeur (qui émule en ligne), mais en ligne, et surtout la synchronisation des barres en ligne est nécessaire (pour les Expert Advisors appropriés).
Pour moi, les expériences de test sont nécessaires pour évaluer les résultats du trading sur l'historique. Et mon choix du commerce en ligne dépend de cette évaluation. Par conséquent, le problème de ce sujet est le problème du testeur, pas le problème en ligne, c'est pourquoi nous avons besoin de la synchronisation des barres dans le testeur aussi (pour les conseillers experts concernés). Quelques images miroir))))
Marketeer:
Ce que j'essaie de faire remarquer, c'est que la catégorie "exactitude" a maintenant été remplacée par l'identité des parcours des testeurs, mais cela ne signifie pas que ces données sont moins faussées. En particulier, vous avez maintenant choisi un intervalle de 10 secondes, qui est sans aucun doute plus déformant que, par exemple, un intervalle de 5 secondes ou de 1 seconde. En d'autres termes, vous exploitez une caractéristique des conditions de fonctionnement du testeur qui vous donne la méthode préférée avec la minuterie de 10 secondes.
Oui, plus l'intervalle est petit, plus le résultat est précis. Mais, en fait, c'est nécessaire, du moins pour moi, pour le dernier test. Et pour le préliminaire, je serais toujours d'accord avec Vladimir(MetaDriver) que l'intervalle d'une minute est suffisant.
Marketeer:
En fait, avec les événements de minuterie, vous essayez de "rattraper" l'arrivée des ticks des nouvelles barres sur tous les symboles, et il est évident que la meilleure façon de le faire est l'événement OnTick.
Et là, vous pouvez voir que vous n'avez pas lu attentivement le premier message du fil de discussion. Pas avec les événements du timer, mais avec OnChartEvent(). Ou est-ce une erreur d'impression ?
J'en déduis que par "exécution réelle", vous entendez un test en ligne, où plusieurs EA fonctionnent et où chacun s'accroche directement à son propre symbole. Si c'est ce que vous voulez dire, alors une question. Pourquoi avons-nous besoin de la synchronisation des barres dans ce cas, si chaque Expert Advisor est situé sur son propre symbole ? La synchronisation des barres dans ce cas est peut-être nécessaire lorsque le système de trading est conçu de telle manière qu'une décision est prise sur la base de plusieurs symboles à la fois, de sorte que les barres sur ces plusieurs symboles doivent être formées.
C'est à peu près comme ça.
Et là, vous pouvez voir que vous n'avez pas lu attentivement le premier message du fil de discussion. Pas avec les événements du timer, mais avec OnChartEvent(). Ou est-ce une erreur d'impression ?
Pourquoi le serait-elle ? Vous avez OnTimer comme troisième numéro. Vous avez déjà été cité à ce sujet : il suffit d'implémenter une méthode qui réalisera correctement le test. Vous l'avez. Il s'agit de la fonction OnTimer () avec un intervalle minimum. Donc vous devez avoir quelque chose d'autre en tête.
Il y en a un - EURUSD, mais le conseiller expert négocie sur EURUSD à partir du graphique GBPUSD. Et les résultats sont identiquement faux.
Si c'est important pour vous, je vous recommande quand même de demander aux développeurs quel est l'analogue du fichier fxt dans 5. J'ai déjà écrit qu'il est fort probable que des bases de tics différentes soient générées pour des tests différents.