Que diable se passe-t-il ? - page 4
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
Et essayez de désactiver la logique actuelle et de la remplacer par un assistant ordinaire. Vous verrez immédiatement où le chat s'est trompé, dans la logique ou l'exécution.
bon conseil.... Nous ne devrions pas en arriver à penser que l'optimisation n'est rien d'autre que des instances séparées d'exécutions uniques, c'est du moins ce que les utilisateurs souhaiteraient et ce que les développeurs voulaient.
Cela signifie que, quelle que soit la complexité de l'algorithme du conseiller expert, le résultat d'une seule exécution devrait être identique à celui obtenu dans un groupe d'exécutions pendant l'optimisation.
J'imprimerais (comme Renat le conseille) à la fin de chaque exécution pendant l'optimisation l'historique des transactions dans un fichier contenant les paramètres (pour faciliter la recherche parmi une pile de fichiers créés) et je ferais de même pour une seule exécution, de cette façon il sera possible de trouver la différence de résultats après l'optimisation et une seule exécution. il semble que ce soit la seule façon d'atteindre la vérité.
cependant, je suis très curieux de savoir ce qui, quelle nuance, peut causer des résultats différents dans l'optimisation et l'exécution unique, car la logique suggère que cela est impossible en principe, à condition qu'une exécution unique soit identique à celle de l'exécution par lots de l'optimisation.
" presque toutes les données sont initialisées dans une boucle ".
Les gars, vous ne pouvez pas initialiser dans une boucle. Vous devez lire dans la boucle.
Je vous ai montré dans quels cas c'est non seulement possible, mais nécessaire et il n'y a pas d'autre moyen.
@Andrey Dik, je me demande exactement comment boulonner l'impression au(x) fichier(s). Il semble que le fichier devrait être écrit au fur et à mesure. Et qu'est-ce qu'il faut y écrire exactement ? Les prix ne sont pas informatifs. Vous devez écrire des informations qui vous aideront à comprendre la raison de la divergence. Quel genre d'information ? Où peut-on le trouver ? Je n'en ai pas encore la moindre idée.
@Andrey Dik, je me demande exactement comment boulonner l'impression au(x) fichier(s). Il semble que le fichier devrait être écrit au fur et à mesure. Et qu'est-ce qu'il faut y écrire exactement ? Les prix ne sont pas informatifs. Vous devez écrire des informations qui vous aideront à comprendre la raison de la divergence. Quel genre d'information ? Où peut-on le trouver ? Je n'ai pas encore d'idées.
Dans la fonction OnTester(), créez un fichier appelé InputName1 + "_" + InputName2 + "_" + InputName3 + "_" + InputName4 + "_" +..... et y enregistrer l'historique de toutes les transactions (et non des positions). Toutes les informations nécessaires à l'analyse, le temps, le prix, etc. seront enregistrées. Vous pouvez également écrire dans ce fichier quelque chose d'autre de très intéressant pour un EA particulier, qui peut être utile pour rechercher des incohérences entre l'optimiseur et une seule exécution.
N'oubliez pas de vérifier MQLInfoInteger (MQL_OPTIMIZATION)) ; pour ajouter postfix dans le nom du fichier à l'exécution unique, afin de ne pas écraser le même fichier après l'optimisation.
SZY. Si vous obtenez deux fichiers avec des contenus différents, cela ne sera pas suffisant pour les développeurs, mais vous donnera seulement la direction où creuser plus loin, vous devrez apporter le code reproductible du problème. avec un peu de chance, le problème est dans le code EA.
Dans la fonction OnTester(), créez un fichier nommé InputName1 + "_" + InputName2 + "_" + InputName3 + "_" + InputName4 + "_" +..... et y enregistrer l'historique de toutes les transactions (et non des positions). Toutes les informations nécessaires à l'analyse, le temps, le prix, etc. seront enregistrées. Vous pouvez également écrire dans ce fichier quelque chose d'autre de très intéressant pour un EA particulier, qui peut être utile pour rechercher des incohérences entre l'optimiseur et une seule exécution.
N'oubliez pas de vérifier MQLInfoInteger (MQL_OPTIMIZATION)) ; pour ajouter postfix dans le nom du fichier à l'exécution unique, afin de ne pas écraser le même fichier après l'optimisation.
SZY. Si vous obtenez deux fichiers avec des contenus différents, cela ne sera pas suffisant pour les développeurs, mais vous donnera seulement une direction où creuser ensuite, vous devrez citer un problème de code reproductible. J'espère que le problème est dans le code EA.
Merci. Je le ferai.
Merci. C'est ce que je vais faire.
Merci. Je le ferai.
Vérifier l'initialisation des variables déclarées globalement.
Si l'initialisation n'est pas dans OnInit() mais dans la déclaration et si leurs valeurs sont modifiées dans le code.
Vérifier l'initialisation des variables déclarées globalement.
Si l'initialisation n'est pas dans OnInit(), mais dans la déclaration et si leurs valeurs sont modifiées dans le code.
que les variables soient initialisées ou non, mais les résultats doivent coïncider dans les deux modes du testeur (optimisation et exécution unique)
bon conseil.... Nous ne devrions pas en arriver à penser que l'optimisation n'est rien d'autre que des instances séparées d'exécutions uniques, c'est du moins ce que les utilisateurs souhaiteraient et ce que les développeurs voulaient.
Cela signifie que, quelle que soit la complexité de l'algorithme du conseiller expert, le résultat d'une seule exécution devrait être identique à celui obtenu dans un groupe d'exécutions pendant l'optimisation.
J'imprimerais (comme Renat le conseille) après la fin de chaque exécution pendant l'optimisation l'historique des transactions dans un fichier contenant les paramètres (pour faciliter la recherche parmi le tas de fichiers créés) et je ferais la même chose pendant une seule exécution, ainsi il serait possible de trouver la différence des résultats après l'optimisation et une seule exécution.
cependant, je suis très curieux de savoir ce qui, quelle nuance, peut causer des résultats différents dans l'optimisation et l'exécution unique, car la logique suggère que cela est impossible en principe, à condition qu'une exécution unique soit identique à celle de l'exécution par lots de l'optimisation.
En général, je suis d'accord avec vous. Si owl ne fait vraiment pas de branchements en fonction de l'environnement (qu'il tourne en mode optimiseur ou en mode testeur), alors la seule chose que nous pouvons supposer est qu'en mode optimisation, certains appels api dans le mode testeur sont trop optimisés pour la vitesse, pardonnez la tautologie. Peut-être cela dépend-il des drapeaux dans les fonctions utilisées. Un journal détaillé des transactions et des résultats d'exécution serait utile, oui.
Je ne l'ai pas rencontré personnellement.
que les variables soient initialisées ou non, mais les résultats doivent correspondre dans les deux modes du testeur (optimisation et exécution unique)
déclarer une variable de manière globale et l'initialiser lors de la déclaration, par exemple, int kk=0 ;
puis, dans OnTick(), désimprimer et modifier la valeur, par exemple Print("kk=",kk) ; ++kk ;
puis changer de TF ou de paramètres -- et voir le résultat.