Erreurs, bugs, questions - page 748
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
La demande a été acceptée. Plusieurs bogues ont été corrigés dans le testeur, ce qui entraînait une divergence entre les résultats de l'optimisation et ceux du test unique.
Par conséquent, c'est à vous (en tant qu'auteur de l'EE) de fournir la preuve que la nouvelle construction n'a pas été entrée (ou sortie) correctement. Le plus tôt vous le ferez, le mieux ce sera pour tout le monde. C'est beaucoup plus difficile pour nous que pour vous, l'auteur.
J'ai exécuté l'optimisation avec un paramètre fictif (j'ai défini 1000 passes).
En conséquence, Cloud a fièrement rapporté ce qui suit :
local 0 tâche(0%), distant 0 tâche(0%), cloud 512 tâches(100%) ? ? ??
Total des passes 484 (457 passes réussies)
Parmi ceux-ci :
15 fois, résultat 5605.09 (comme si les agents de la version précédente fonctionnaient, correspond à un seul test des versions précédentes - 642, 619)
442 fois 7175.27 (correspond à l'unique test de la build 665)
Beaucoup de messages "impossible de synchroniser l'historique", "impossible d'initialiser l'expert", "pas de mémoire", "expert rejeté par MQL5 Cloud Network en raison d'une boucle sans fin".
construire 655
les agents distants refusent de participer à l'optimisation pour certains symboles.
Par exemple : pour EURUSD - tout est OK, pour EURJPY - optimisation uniquement sur l'agent local.
L'histoire des outils utilisés pendant la période d'essai, pour autant que je sache, n'a pas changé.
Il y avait un problème de longue date avec des conteneurs "cassés" qui se comportaient comme s'ils étaient intacts pendant la synchronisation des données (même l'agent du cloud a trouvé un conteneur de ce type sur mon ordinateur, ce qui a permis de localiser le problème). Ces conteneurs sont maintenant tués et remplacés lors de la resynchronisation. Par conséquent, on pourrait dire que l'histoire a peut-être changé.
"Attendez que la mousse se calme et demandez un nouveau remplissage". Attendons quelques jours.
construire 655
les agents distants refusent de participer à l'optimisation pour certains symboles.
Par exemple : pour EURUSD - tout est ok !, pour EURJPY - optimisation uniquement sur l'agent local.
Avez-vous accès aux journaux des agents à distance ?
Si oui, veuillez les fournir au service d'assistance.
Je voudrais demander si le problème sera résolu pour sauter les week-ends à l'avenir, conformément à la demande#318662.
J'ai mis une ligne sur le graphique le 18 juin, mais il y a 6 jours ouvrables et 36 barres avant cette date.
Personnellement, je veux mettre les fuseaux horaires Fibo dans le futur et voir la date, mais ce sera faux.
Ou l'expiration des futures sera le 18 juin. Mais ce ne sera pas là où se trouve la ligne, mais là où se termine le rectangle...
J'aimerais savoir si le problème sera résolu afin de pouvoir sauter les week-ends à l'avenir. Sur la demande#318662.
Regardons la photo de l'autre terminal... Eh bien, il est réaliste d'estimer le temps de développement de telle ou telle variante, quand je peux voir l'emplacement exact de la date...
En haut du graphique, il y a le 18 juin. Et il y a vraiment 36 barres... Et où est notre 18...
Il y avait un problème de longue date avec des conteneurs "cassés" qui se comportaient comme s'ils étaient intacts pendant la synchronisation des données (même l'agent du cloud a trouvé un conteneur de ce type sur mon ordinateur, ce qui a permis de localiser le problème). Ces conteneurs sont maintenant tués et remplacés lors de la resynchronisation. Par conséquent, on pourrait dire que l'histoire a pu changer.
"Attendez que la mousse se calme et demandez un nouveau remplissage". Attendons quelques jours.
Dans ce contexte, le "conteneur" est quoi ?
Est-ce que je comprends bien que si, après le remplacement des conteneurs, on exécute le testeur de la version 642, il devrait donner le même résultat que la version 665 ?
Dans ce contexte, le "conteneur" est quoi ?
Ai-je raison de supposer que si, après le remplacement des conteneurs, vous exécutez le testeur de la version 642, il devrait afficher le même résultat que la version 665 ?
Un conteneur est un dépôt d'une partie des données historiques.
Oui, vous comprenez bien. Le problème se situait au niveau des agents de test, pas du testeur lui-même.
Le conteneur est le dépositaire d'une partie des données historiques.
Oui, vous comprenez bien. Le problème se situait au niveau des agents de test, pas du testeur lui-même.
Quelque chose ne fonctionne pas :
Je supprime l'historique de 2011 dans Tester (Tester\bases\metaquotes-demo\history\...\2011.hcs) et Metatrader (bases\metaquotes-demo\history\...\2011.hcs)
Je fais le test (plusieurs passages) dans la version 655 - l'historique est téléchargé, les fichiers supprimés apparaissent, j'obtiens le résultat 7175.27.
Je change le testeur en build 642, je lance le test. L'historique pour l'année 2011 ne change pas. J'obtiens un résultat de 5605.09 ! ?!
Build 642 enregistre 11752200 ticks, 665 enregistre 11752140.