La décélération linéaire est-elle une erreur de programmation ou une caractéristique de MT4 ? - page 11
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
J'aimerais vraiment savoir qui est MetaQuotes, puis-je prendre un message ?
J'ai jeté un rapide coup d'oeil au code. Un passage du poème de Lermontov m'est immédiatement venu à l'esprit :
Maintenant, à votre question :
-Aleks :
Au stade du raffinement de la stratégie, et surtout de la tactique, il faut commander toutes sortes d'ajouts pour tester l'idée, à ce stade il est tout à fait possible de tolérer la lenteur du conseiller expert.
Mais j'ai été surpris par cette vitesse 6 fois plus lente que celle de la version principale de l'EA. L'optimisation duréglage de l'EA est nécessaire au moins pour la collecte de données analytiques.
Ai-je raison de comprendre qu'il est impossible de lire le code d'autres personnes et qu'il vaut mieux commander une autre version de l'EA après avoir obtenu un succès, mais qu'il doit être écrit à partir de zéro, et que ce n'est que dans ce cas que nous pouvons être sûrs de la vitesse et de la fiabilité ? Personnellement, je pense que la partie de la tâche du compilateur consiste à supprimer les opérations en double, par exemple...
Je ne parle pas de ce code, mais du monde en général. Vous réfutez donc cette affirmation ?Si vous commandez un programmeur qui écrit dans le style "chevaux et personnes mélangés" - vous devez réécrire non pas deux ou trois fois, mais tout le temps et toujours à 100%, pour tout budget croissant. Si vous faites appel à des professionnels, une modification des exigences de 20 %, 40 % ou même 80 % ne nécessitera pas de réécrire le code non seulement complètement, mais même sur le même pourcentage que les modifications. Mais avec un budget de "<$50", oubliez-le.
Ai-je raison de supposer qu'il devrait y avoir un retard artificiel dans l'envoi des ordres aux ordres ouverts, mais sans attendre la confirmation de leur ouverture ?
Bien entendu, le conseiller-expert doit gérer toute erreur d'envoi d'ordre. Dans le cas le plus simple - pour afficher un message sur l'échec de l'ouverture de l'ordre. Dans la version plus avancée, il décidera des actions ultérieures.
J'ai donc besoin d'un EA pour me remplacer, et d'autres actions sont très pertinentes ici... Mais il n'est pas sûr qu'elles soient opportunes (par exemple, le prix s'est déjà beaucoup éloigné du point d'entrée calculé).
Je ne l'ai pas laissé envoyer. Demandez au codeur d'utiliser IsTradeContextBusy pour vérifier.
Merci pour le conseil, mais je parlais justement de ces nuances dans le fil suivant. Comment pourrais-je le savoir ?
Si vous utilisez la version 509, il y a 8 threads et la situation avec IsTradeContextBusy ne devrait pas se produire.
Si c'est le cas, voir le point ci-dessus.
Vous pouvez également utiliser plus d'un terminal.
Je ne comprends pas, est-ce que le nombre de terminaux affecte le passage d'un ordre ? Je veux dire, on peut lancer plusieurs terminaux pour un seul et même compte et envoyer un ordre d'ouverture d'un ordre depuis chaque terminal et si la moitié d'entre eux claque, l'autre moitié exécutera l'ordre avec succès ? Je pensais que l'ordre devait être traité par le DC et seulement ensuite accepter le suivant....
J'ai jeté un coup d'œil rapide au code. Un passage du poème de Lermontov m'est immédiatement venu à l'esprit :
Maintenant, à votre question :
Si vous commandez un programmeur qui écrit dans le style "personnes et chevaux mélangés", vous devez le réécrire non pas deux ou trois fois, mais tout le temps et toujours à 100%, pour le budget toujours croissant. Si vous faites appel à des professionnels, une modification des exigences de 20 %, 40 % ou même 80 % ne nécessitera pas de réécrire le code non seulement complètement, mais même sur le même pourcentage que les modifications. Mais avec un budget de "<$50", oubliez-le.
Pour l'instant, il me coûte plus de 100 dollars et je sais que je vais en rajouter. Le calcul est le suivant :
10 révisions à 30 $ vous donnent un coût de 300 $, tandis que 10 à 50 $ vous donnent un coût de 500 $. Une économie de 200 $ est importante pour moi. Mais lorsque j'en serai satisfait, je pourrai commander une EA à partir de zéro (en supprimant les choses inutiles) et elle coûtera environ 80 $. Cette approche se justifie d'elle-même, surtout lorsque le développement est en cours. Sauf que tu dois user tes nerfs... mais c'est comme ça que la chance tourne.
Vous vous trompez. Il ne doit pas y avoir de retards artificiels. MT5 dispose d'un modèle d'événement simple qui devrait être utilisé à la place des délais sleep().
Merci pour le conseil, mais ce sont les nuances dont j'ai parlé dans le fil suivant. Comment dois-je les connaître ?
Je n'ai pas besoin d'y entrer et de chercher quelque chose.
Si quelqu'un vous a indiqué comment cela devrait être, et que vous trouvez un manque dans votre code, vous feriez mieux de changer le codeur en silence. Ne pas créer de branches.
Je ne comprends pas, est-ce que le nombre de terminaux affecte la façon dont un ordre est transmis ? C'est-à-dire que vous pouvez utiliser plusieurs terminaux sur le même compte et envoyer un ordre pour ouvrir un ordre à partir de chacun d'entre eux, et si la moitié d'entre eux sont bloqués, alors l'autre moitié exécutera l'ordre avec succès ?
Le nombre de terminaux sera égal au nombre de fils à envoyer. 10 terminaux enverront 1 commande - il y aura 10 commandes.
J'ai donc besoin d'un EA pour me remplacer, et d'autres actions sont très pertinentes ici... mais il n'est pas sûr qu'elles soient opportunes (par exemple, le prix s'est déjà beaucoup éloigné du point d'entrée calculé).
Pour l'instant, le conseiller expert me coûte plus de 100 dollars et je sais que je vais en ajouter d'autres. Voilà pour le calcul :10 révisions à 30 $ donnent une dépense de 300 $, tandis que 10 à 50 $ donnent une dépense de 500 $. Economiser 200 dollars, c'est important pour moi. Mais lorsque j'en serai satisfait, je pourrai commander mon conseiller expert à partir de zéro (en supprimant les choses inutiles) et il coûtera 80 dollars. Cette approche se justifie d'elle-même, surtout lorsque le développement est en cours. Sauf que tu dois user tes nerfs... mais c'est une question de chance.
C'est une mauvaise approche de votre part.
Vous commandez le code pour le testeur, vous l'avertissez de l'importance de la vitesse d'optimisation, vous y apportez les améliorations nécessaires. Et ce n'est qu'une fois que la version d'essai est prête que vous commandez la version réelle avec une logique entièrement testée et toutes les modifications/recommandations.
Vous économiserez beaucoup plus d'argent. Non ?
Je n'ai pas besoin de les examiner pour savoir ce qu'il en est.
Si quelqu'un vous a suggéré comment cela devrait être, et que vous trouvez un manque dans le code - changez silencieusement le codeur. Ne pas créer de branches.
le nombre de terminaux - la même multiplicité de fils à envoyer. 10 terminaux enverront 1 commande - il y aura 10 commandes.
Et qu'en est-il de la société de courtage ? Après tout, c'est le terminal qui a une commande bloquée ! Quelle est alors la raison d'envoyer une multitude d'ordres ?
C'est une mauvaise approche de votre part.
Vous commandez le code pour le testeur, en lui notifiant l'importance de la vitesse d'optimisation, et y introduisez les améliorations nécessaires. Et seulement après que la version de test soit prête, commandez la version réelle avec une logique complètement déboguée et toutes les modifications/recommandations nécessaires.
Vous économiserez beaucoup plus d'argent. Non ?
Eh bien, pour commencer, je n'ai pas suggéré initialement que la vitesse des tests dépendait beaucoup du testeur ou de la mise en œuvre réelle.
Et pour le reste, c'est ce que je fais, je teste, j'affine... ou êtes-vous en train de dire que le prix sera beaucoup moins élevé si j'écris immédiatement "Je ne suis pas pour de vrai, mais je teste" ?
Et pour le DC ? Après tout, c'est lui qui a un ordre coincé ! ? Quel sens cela a-t-il alors d'envoyer un tas d'ordres ?
Si vous n'avez pas besoin d'envoyer une douzaine de commandes d'un coup, alors je n'insiste pas.
Vous pouvez envoyer un par un depuis un terminal et attendre que le contexte se libère et ainsi de suite.
La douzaine entière peut être envoyée en quelques minutes.
Non, eh bien, si vous n'avez pas besoin d'une douzaine à la fois, alors je n'insiste pas.
Vous pouvez en envoyer un à la fois depuis un terminal, attendre que le contexte se libère, et ainsi de suite.
Vous pourriez être en mesure d'en envoyer une douzaine en quelques minutes.
Je pose donc la question, car je ne sais pas comment les ordres sont traités par les sociétés de courtage - en parallèle ou séquentiellement ?
en parallèle ou en séquentiel ?
Les offres arrivent de manière séquentielle. Mais il n'est pas certain que l'achat sera exécuté plus rapidement que la vente suivante, car il y a parfois un autre fournisseur de liquidités.
Mais pour simplifier le monde - pensez toujours que cela va en série.
la seule raison de cette information est de rester dans le sujet.