La décélération linéaire est-elle une erreur de programmation ou une caractéristique de MT4 ? - page 6
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
Vous devez arrêter de perdre du temps et commencer enfin à développer. Rédigez les TdR.
Le client veut une solution, pas un simple délai.
Il vous a été expliqué pour la énième fois par une personne expérimentée que dans ce code, en un seul passage de la fonction start
32 cycles "pour".
17 fois vous scannez les ordres (ouverts et historiques),
24 appels de la fonction de suppression des ordres en attente, qui a également un cycle pour tous les ordres (* nombre d'ordres)
7 appels de la fonction de suppression des ordres de bourse avec le même cycle pour tous les ordres (*nombre d'ordres)
6 modifications de Limites avec cycles à l'intérieur (* nombre de commandes)
6 modifications des ordres stop avec des cycles à l'intérieur (* nombre d'ordres)
Appels de fonctions de 10 ordres avec des cycles à l'intérieur (*nombre d'ordres)
37 fois que vous imprimez (Imprimer),
7 (sept) fois, vous accédez à l'historique complet des barres pour toute l'histoire (et il s'accroît pendant les tests).
Et ça prend beaucoup de temps.
Je ne parle même pas des filtres "if" non optimisés, des conditions compliquées qu'ils contiennent (et il n'y a pas de vérification abrégée dans MT4).
Et après cela, vous pouvez fermer les yeux sur un code absolument illisible, ce n'est pas important, au moins vous pouvez le passer dans un styler et obtenir quelque chose (bien que personnellement je n'aime pas son style) :
Je vais peut-être le répéter, mais ! Le premier et probablement le principal problème est que le code est illisible et non structuré. Votre cahier des charges est peut-être très clair. Si vous comprenez le cahier des charges et que vous écrivez le code correctement, cela donne (en règle générale) un bénéfice considérable en termes de vitesse d'exécution, mais cela coûte aussi un peu d'argent.
En résumé, vous avez besoin d'un organigramme, qui vous montrera ce qui est exécuté inutilement. Pour les programmeurs débutants (lire "traders"), il serait pratique de voir une telle visualisation de code au moyen du programme MT4.
L'optimisation la plus simple, telle que je la comprends, est de systématiser le code pour travailler avec les ordres, à savoir faire seulement 2 requêtes principales par barre et en plus par 1 tick, si les conditions des TdR exigent de travailler avec les ordres quand certaines conditions se produisent, comme résultat nous recevrons
1. vérifier les conditions pour mettre à niveau/fermer un ordre lorsqu'une nouvelle barre s'ouvre ;
2. modifier/fermer la commande
3. Vérifier les conditions d'ouverture d'un nouvel ordre lorsqu'une nouvelle barre est ouverte.
Ouvrir une nouvelle commande ; 4.
5. Vérification des conditions de mise à niveau des barres à chaque tick
6. Modernisation/Fermeture d'un ordre lorsque la condition 5 est remplie.
Mais un programmeur m'a dit que le code sera de toute façon exécuté à chaque tick (vérification complète de la conformité de l'ordre, pas seulement cette partie, qui devrait être vérifiée à chaque tick).
La fonction "imprimer" ralentit-elle le conseiller expert pendant l'optimisation ?
Quel fichier avez-vous joint après l'avoir exécuté dans le "styler" ?
FAQ:
который вы выложили в первом посте темы.
Quant à "le code sera toujours exécuté à chaque tick (vérification complète par rapport au RPT, pas seulement la partie qui doit être vérifiée à chaque tick)", pouvez-vous commenter ?
Et pour ce qui est de "le code sera toujours exécuté à chaque tick (vérification complète de la conformité avec les RPT, pas seulement la partie qui devrait être vérifiée à chaque tick)", quel est votre commentaire ?
Vous devez le refaire, vous devez le refaire avec sagesse. Ensuite, tout fonctionnera comme et quand il le faudra.
Je ne parle pas de ce code, mais globalement. Vous réfutez donc cette affirmation ?
Je ne parle pas de ce code, mais globalement. Vous réfutez donc cette affirmation ?
Ne vous engagez pas dans la théorie. Vous ne comprendrez rien de toute façon.
Toute théorie sans code ou application spécifique n'est que pure absurdité.
Si vous voulez le réfuter ou le prouver, faites le code et voyez comment il se comporte.
Ne vous engagez pas dans la théorie. Vous ne comprendrez rien de toute façon.
Toute théorie sans code ou application spécifique n'est que du bavardage.
Si vous voulez le réfuter ou le prouver, faites le code et voyez comment il se comporte.
Il y a probablement beaucoup de choses que je ne comprends pas, mais j'essaie de les comprendre...
Réfléchir à votre appel à l'action...
Mais en essayant de le comprendre...
Tant que vous n'aurez pas ouvert MetaEditor et commencé à écrire votre propre code, vous ne comprendrez jamais comment il fonctionne.
Et même un petit proger débutant écrasera toutes vos connaissances théoriques par ses compétences pratiques et ses observations empiriques.
Si vous n'avez pas l'intention d'"écrire votre propre code", ne demandez même pas à ce forum pourquoi quelque chose traîne, car cela n'a aucun sens pour vous.
Ou bien avez-vous décidé de devenir un codeur professionnel sur les conseils du forum ? :)))) Le nom du thème "décélération linéaire" nous indique que vous avez étudié dans un département scientifique ou que vous êtes ingénieur.
Il n'y a pas de théoriciens en programmation, tout comme il n'y a pas de footballeurs professionnels/entraîneurs/surgeurs/linguistes qui sont des théoriciens et n'ont jamais été dans la pratique.
Tous vos efforts pour découvrir les raisons pour lesquelles le programme ne fonctionne pas ne doivent pas se situer sur le plan du "je veux savoir", mais sur le vecteur concret du "dois faire".
Tous les autres raisonnements théoriques avec de grandes notions ne valent pas un sou sans actions concrètes.
Et un peu d'humour pour aller droit au but.
Tant que vous n'aurez pas ouvert MetaEditor et commencé à écrire votre propre code, vous ne comprendrez jamais comment il fonctionne.
Et même un petit proger débutant écrasera toutes vos connaissances théoriques par ses compétences pratiques et ses observations empiriques.
Si vous n'avez pas l'intention d'"écrire votre propre code", alors ne commencez même pas à demander au forum pourquoi quelque chose traîne, car cela n'a aucun sens pour vous.
Ou avez-vous décidé de devenir un pro du codage sur les conseils du forum ? :))) Le nom du sujet "freinage linéaire" nous indique que vous avez étudié dans une école de sciences ou d'ingénierie.
Il n'y a pas de théoriciens en programmation, tout comme il n'y a pas de footballeurs professionnels/entraîneurs/surgeurs/linguistes qui sont des théoriciens et n'ont jamais été dans la pratique.
Tous vos efforts pour découvrir les causes de l'échec du programme doivent se situer non pas sur le plan du "je veux savoir", mais sur un vecteur particulier du "dois faire".
Tous les autres raisonnements théoriques avec des notions pompeuses ne valent pas un sou sans actions concrètes.
Et un peu d'humour sur le sujet.
Merci pour l'humour !
Mais à ce propos, mon travail professionnel se situe dans le domaine de l'optimisation fiscale, donc je suis familier avec les algorithmes ;) Je pense que mes RPT sont compréhensibles, bien sûr après avoir spécifié les détails (j'essaie de faire des dessins et des calculs en Excel).
De plus, je suis familier avec MetaEditor, et je suis capable de faire un indicateur simple ou de corriger la logique d'un Expert Advisor. Mais j'ai un gros problème avec les fonctions commerciales... Je suis actuellement limité dans le temps, et je ne me sens pas un programmeur né, mais j'ai besoin de comprendre les bases et les caractéristiques du langage MQL, afin de défendre mes intérêts dans la réalisation de ma commande.
Et puis je suis vraiment curieux.