Résultats du test expert multi-devises - page 6

 
tol64:

Pourquoi vous en prendre à cette deuxième source ?)

Si je commence à répondre sur le fond, la réponse sera soit quelque chose comme"des phrases arrachées séparément", soit"je ne suis pas le genre de personne qui pense avoir toujours raison sur tout". C'est déjà clair.

Pour ce qui est du ping-pong, c'est une position un peu étrange à prendre. Vous vous intéressez à un sujet, vous obtenez des réponses et des questions suggestives, et vous commencez soit à les contester, soit à les balayer d'un revers de main. Avez-vous ou qui a besoin de ce sujet en premier lieu ? Je n'ai personnellement pas besoin de ces résultats et le résultat de votre choix ne m'intéresse guère. Le sujet lui-même semblait digne d'attention, mais le zèle polémique de l'auteur fait douter de l'opportunité de son maintien.

 
marketeer:

Pourquoi le serait-elle ? Vous avez OnTimer comme troisième numéro ici. Vous avez déjà été cité à ce sujet : il suffit d'implémenter une méthode qui réalisera correctement le test. Il y en a un. Il s'agit de la fonction OnTimer () avec un intervalle minimum. Donc vous devez avoir quelque chose d'autre en tête.

Avant ça, vous avez écrit ça :

Mais ce n'est pas la même chose :
En fait, vous essayez d'attraper le moment où les nouvelles barres sont affichées sur tous les symboles et il est évident que la meilleure façon de le faire est d'utiliser l'événement OnTick.


Le problème est que je n'essaie pas d'attraper les ticks dans OnTimer(). Dans OnTimer(), la vérification d'une nouvelle barre est effectuée pour chaque symbole séparément. Cette vérification est effectuée à un intervalle défini dans la minuterie (en secondes).

Un événement tel qu'un tick est reçu dans la fonction OnTick() et dans le schéma proposé par Konstantin Gruzdev, c'est-à-dire dans la fonction OnChartEvent(). Dans OnChartEvent(), nous pouvons suivre n'importe quel événement, y compris la formation d'une nouvelle barre sur n'importe quel intervalle de temps.

Il n'y a aucun problème avec la minuterie. Maintenant je teste l'EA multi-devises de la manière suivante

1. J'optimise les paramètres pour chaque symbole séparément, en attachant l'EA au symbole dont les paramètres sont optimisés. Le processus d'optimisation est effectué à l'aide de la fonction OnTick(). Au moment de l'optimisation des paramètres pour un symbole, tous les autres symboles sont désactivés, c'est-à-dire qu'ils ne participent pas aux tests et que les transactions sont effectuées uniquement pour le symbole dont les paramètres sont optimisés.

2. Après l'optimisation des paramètres pour tous les symboles, nous devons tester tous les symboles en même temps. Je déplace le code vers la fonction OnTimer() (pour l'instant), j'active le timer pour un test préliminaire (60 secondes) et j'analyse le résultat obtenu. Si je suis satisfait, je mets au point le système de gestion de l'argent et d'autres sous-systèmes. Ensuite, j'active le test final (minuterie de 10 secondes) et je reçois, à mon avis, le résultat le plus précis. Mon point de vue et mes conclusions sont basés sur les résultats des tests de toutes les méthodes et sur la comparaison de ces résultats entre eux.

marketeur :
Si c'est important pour vous, je vous recommande quand même de vérifier auprès des développeurs quel est l'analogue du fichier fxt dans Five. J'ai déjà écrit que des bases de tics différentes sont susceptibles d'être générées pour des tests différents.

C'est une hypothèse intéressante. C'est peut-être même le cas. Une réponse des développeurs serait donc la bienvenue.

 
Il n'y a pas de fichiers fxt dans mt5. Maintenant, les ticks ne sont pas écrits dans un fichier, mais modélisés à la volée à partir de l'historique des minutes.

Il s'avère que la génération de ticks à la volée est plus rapide que leur lecture depuis le disque.
Документация по MQL5: Файловые операции / FileWrite
Документация по MQL5: Файловые операции / FileWrite
  • www.mql5.com
Файловые операции / FileWrite - Документация по MQL5
 
Renat:
Il n'y a pas de fichiers fxt dans mt5. Maintenant, les ticks ne sont pas écrits dans un fichier, mais modélisés à la volée à partir de l'historique des minutes.

Il s'avère que générer des ticks à la volée est plus rapide que de les lire depuis le disque.
Bonjour Renat. Je vous remercie de votre réponse. C'est une excellente nouvelle.
 
tol64:
Bonjour Renat. Je vous remercie de votre réponse. C'est une excellente nouvelle.
Je ne vois rien de génial, il s'avère que dans mt5 vous ne pouvez pas tester sur des ticks réels.
 
Loky:
Je ne vois rien de génial, il s'avère que dans mt5 vous ne pouvez pas tester sur des ticks réels.
Aimeriez-vous pouvoir collecter votre propre base de chat ou la prendre quelque part et la tester ?
 
Yedelkin:

Si je commence à répondre sur le fond, la réponse sera soit quelque chose du genre"phrases extraites séparément", soit"je ne suis pas le genre de personne qui pense avoir toujours raison sur tout". C'est déjà clair.

Non. Il semble que vous ne compreniez toujours rien. Et maintenant, je vais vous l'expliquer pour la quatrième fois. Remettons notre dialogue sur les rails.

Tout a commencé à partir de ce moment:

Yedelkin:
Faites attention à la partie du code :

int OnInit()
{
if(iCustom("EURUSD",PERIOD_D1,"Spy Control panel MCM",ChartID(),0,CHARTEVENT_TICK) == INVALID_HANDLE)
   { Print("Ошибка установки шпиона на EURUSD"); return(true);}
   
if(iCustom("GBPUSD",PERIOD_D1,"Spy Control panel MCM",ChartID(),1,CHARTEVENT_TICK) == INVALID_HANDLE)
   { Print("Ошибка установки шпиона на GBPUSD"); return(true);}
}

Ici, vous pouvez voir que vous "articulez" un certain "panneau de contrôle espion MCM" sur deux caractères différents. Vous avez donc différents symboles comme sources de signaux. Mais vous affirmez que "nous traitons sur l'EURUSD", c'est-à-dire que la source du signal est un seul et même symbole. Décidons.

Je vous ai répondu à ce sujet :

tol64 :

Oh, ça se rapproche. Il semble qu'une variante soit apparue, où je me trompe)). Je vais y réfléchir pendant un certain temps et je l'écrirai en détail...

Pensée. Réponse:

tol64 :

Il ne traite que l'EURUSD.

Dans mes tests, je considère le schéma de Konstantin Gruzdev - Implementation of the Multicurrency Mode in MetaTrader 5. ))) Tout est défini. Les fichiers joints contiennent l'indicateur MCM du panneau de contrôle Spy et le conseiller expert exSpy Control Panel MCM. En installant le conseiller expert sur un graphique, vous pouvez voir comment il fonctionne. Le journal montre clairement les événements spécifiques reçus par le conseiller expert à partir de différents symboles. Tout est clair, rien n'est mélangé.

J'ai maintenant essayé de spécifier dans OnChartEvent() le symbole à partir duquel l'ID est reçu, mais cela n'a pas changé les résultats. J'ai supprimé le deuxième caractère de OnInit() pour éliminer toute possibilité de recevoir les mauvais événements. Le test a maintenant été effectué en utilisant cette variante :

...

code

...

photos

...

Les résultats ne correspondent pas. Il n'y a plus de second symbole, les signaux proviennent uniquement de l'EURUSD. Mais cela n'a malheureusement pas résolu le problème.

Le point clé était :"Il n'y a plus de second symbole, les signaux proviennent uniquement de l'EURUSD. Mais cela n'a malheureusement pas résolu le problème."


Vous voyez ? La suppression de la deuxième source n'a pas résolu le problème. La situation était simplifiée et vous auriez pu laisser la deuxième source, mais vous avez continué à citer l'exemple original au lieu d'essayer de résoudre la question suivante. Comment se fait-il qu'en ayant un seul symbole (source unique), mais en échangeant (en mode test) à partir d'un autre symbole, on obtient des variantes non identiques ?

Voici le post où vous avez exprimé cela :

Yedelkin :
Commençons par la formulation correcte. Dans l'exemple initial, vous auriez choisi "trade on EURUSD". En fait, les événements utilisateur 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.

Je te l'ai expliqué une deuxième fois (tu l'appelles "s'envoler" pour une raison quelconque) :

tol64 :

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 symbole GBPUSD é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 vous effectuez des tests sur des barres quotidiennes.

Le fait de retirer une source de signaux, 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 une source de signal qui ne doit pas être testée, mais à partir de laquelle elle doit l'être. 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.

Point clé :"Ce test s'est même avéré superflu. Les résultats n'ont pas changé."
C'est la deuxième fois que vous "ne remarquez pas" que le problème n'est pas ce que vous indiquez, et c'est la deuxième fois que je vous réponds la même chose, mais de manière encore plus explicite.

Vous avez continué :

Yedelkin :
"...tout était bien fait avant" - ceci appartient à la catégorie de la complaisance. C'était mal pour commencer. Apparemment, vous n'accordez pas d'importance à un phénomène tel que le "débordement de la file d'attente des é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".

Étant donné que les fonctions TradeSignalCounter()+TradePerformer() traitent les événements provenant d'une seule source de signaux, l'état de la file d'attente 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, 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.

La période à laquelle le gestionnaire d'événements est testé n'a pas vraiment d'importance. Si le système de Lizar génère des signaux sur une base tick-by-tick, alors ils évaluent la file d'attente des événements sur une base tick-by-tick aussi, pas 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 me donner quelques captures d'écran comparatives sur les modes non-teak de Lizar ?

Et je vous ai répondu pour la troisième fois de la manière la plus polie possible. Et les smileys que vous avez apparemment perçus comme des moqueries, expriment en fait mon amabilité à votre égard. Je vais essayer de ne pas les mettre ailleurs, tant ils sont ambigus.

tol64:

Bonjour ! ))

Outre cette phrase extraite séparément, j'ai également écrit : "... Je n'exclus jamais la possibilité 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. )))

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 :

...
code
...
Pendant l'initialisation, nous spécifions de quel caractère nous recevrons l'événement, et quel événement nous recevrons :
...
code
...

Ainsi, nous n'accepterons l'événement CHARTEVENT_TICK que pour l'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 négociation 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.

...

code
...

L'exécution de ces fonctions est très rapide. La file d'attente des événements n'a pas le temps de déborder et nous ne manquerons aucun événement important. 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.

Qu'est-ce que tu choisis dans cette deuxième source.)))) Il n'y a plus de deuxième source. 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. 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 résultats corrects 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 et voyez où se trouve la divergence.

Et après ça, tu écris :

Yedelkin :
A propos du ping-pong - une position un peu étrange. Vous vous intéressez à un certain sujet, vous obtenez une réponse et posez des questions suggestives, et vous commencez à les contester ou à les rejeter. Avez-vous ou qui a besoin de ce sujet en premier lieu ? Je ne pense pas que quelqu'un fera votre travail à votre place. Personnellement, je me fiche des résultats et les conséquences de vos choix ne m'intéressent guère. Le sujet lui-même semblait digne d'attention, mais la ferveur polémique de l'auteur fait douter de l'opportunité de son maintien.

Ensuite, il y a les questions.

1. À quel genre de réaction vous attendiez-vous, si vous répétez sans cesse la même chose, à savoir que c'est déjà hors de propos et qu'on vous a déjà répondu trois fois ?

2. Si vous avez pris mes réponses comme un argument, vous vous trompez, car j'ai répondu et expliqué ce que je faisais. Mais vous l'avez pris comme un argument parce que vous vous disputiez vous-même. )))

3. Je ne compte jamais sur quelqu'un d'autre pour faire mon travail.

4. je ne suis pas le seul à avoir besoin du sujet, mais tous ceux qui vont rencontrer ce problème. Si vous n'en avez pas besoin, alors pourquoi avez-vous entamé le dialogue ? Ma ferveur polémique n'était qu'une conséquence, la cause venait de vous.

---
Je n'analyserai pas votre comportement du point de vue psychologique, sinon vous et moi devrons nous envoler hors de l'atmosphère. Essayons donc de garder le dialogue court et précis. Mais si vous n'en avez pas besoin, il est préférable de ne pas continuer. Parce que : Veuillez respecter les règles. )))

 

Bien sûr, personnellement, je ne suis pas intéressé par l'analyse des particularités de la vision du monde des autres. J'ai déjà exposé plus haut mes conclusions sur votre ferveur polémique. Il n'y a rien à ajouter.

 
Yedelkin:

... Rien à ajouter.

Ouais, tu ferais mieux de ne pas le faire. Sinon, ce ne sera que du bavardage inutile. Revenons au sujet.

---

J'ai fait une autre série de tests. Les résultats des tests présentés précédemment ont été obtenus en mode - Prix d'ouverture uniquement. A mon avis, j'ai réussi à obtenir des résultats corrects dans ce mode uniquement en utilisant la fonction OnTimer(). Toutes les autres méthodes n'ont pas donné les bons résultats.

Cette fois, j'ai effectué des tests en mode "Tous les tiques" à partir du début de l'année 2011. En même temps, il était intéressant de voir combien de temps prendrait telle ou telle méthode. Par exemple, dans le cadre des tests automatiques des conseillers experts pour le championnat, un conseiller expert doit être testé en mode "Tous les ticks" pendant une durée maximale de 15 minutes. Pour ce test, j'ai construit un conseiller expert simple qui négocie sur 12 paires de devises. Les seules conditions qu'il contient sont le Stop Loss, le Take Profit et le Trailing Stop. Il n'y a pas d'élargissement ou de rétrécissement de la position, pas de système de gestion de l'argent, le lot négocié est fixe (0,1). Le conseiller expert est écrit sans un seul cycle, il est simplifié autant que possible. L'horizon temporel de travail sur tous les symboles est H8.

J'ai optimisé les paramètres pour chaque symbole séparément, à tour de rôle, en utilisant OnTick(). Je n'ai pas attendu que l'optimisation se termine. Après 100 exécutions, j'ai arrêté l'optimisation et choisi non pas la meilleure variante, mais celle qui présentait le risque le plus faible.

La fréquence du processeur sur lequel les tests ont été effectués est de 2 GHz. C'est là qu' il est dit sur quoi se concentrer.

De plus, je remplacerai le mot "identique" par "presque identique", car le but n'est pas d'obtenir une correspondance exacte, mais en analysant le graphique visuellement, les différences ne devraient pas être frappantes.

---

Résultats des tests :

La fonction OnTimer() a été utilisée pour le premier test car elle a donné des résultats presque identiques la dernière fois. Et maintenant, son résultat servira de référence pour la comparaison.

OnTimer()

L'intervalle de la minuterie est de 60 secondes.

Le test a duré 27 minutes.

---

Intervalle de temporisation de 300 secondes :

Les résultats sont presque identiques. La durée du test est de 26 minutes.

---

Intervalle de temporisation 28800 secondes - 8 heures (délai utilisé).

Les résultats sont presque identiques. La durée de l'épreuve est de 25 minutes.

J'ai également effectué des tests avec des intervalles de 1800 et 3600 secondes, les résultats sont également cohérents.

-----------

OnChartEvent()

La période de 1 minute est CHARTEVENT_NEWBAR_M1.

Les résultats sont presque identiques. La durée de l'épreuve est de 37 minutes.

---

Période de 1 minute - CHARTEVENT_NEWBAR_H1.

Les résultats sont presque identiques. Durée du test : 27 minutes.

---

Période de 1 minute - CHARTEVENT_NEWBAR_H8.

Les résultats sont presque identiques. La durée de l'épreuve est de 27 minutes.

----------

OnTick()

Les résultats sont presque identiques. La durée du test est de 72 minutes.

-----------------

En mode "Tous les tics", toutes les méthodes ont donné des résultats presque identiques. OnTick() s'est avéré être la variante la plus longue. La durée du test deOnTimer() et OnChartEvent() est presque identique.

Rapport :

En résumé :

Dans mon cas, même le conseiller expert multidevises le plus simple, qui négocie sur 12 paires de devises sur une très grande échelle de temps (H8), ne peut pas être placé dans le championnat, car il ne passera pas le test (15 minutes pour le test). Nous devrons "couper l'appétit" ou chercher des méthodes pour optimiser au maximum le code du conseiller expert.

---

Je me demande si quelqu'un a réussi un test rapide sur 12 paires ? Combien de temps dure votre test ?

 
tol64:

Je me demande si quelqu'un a réalisé un test rapide sur 12 paires ? Combien de temps dure votre test ?


3.
capr2011 sur EURUSD:H1 chaque tick 2011.01.01-2011.08.01


4. démarrer
terminé en 3 min 21 sec


5. Statistiques
1233 kb de fichiers journaux
100 transactions, 200 transactions, bénéfice 83043.82 USD