Un peu surpris :) J'ai pensé que je devais partager et poser une question NON rhétorique. - page 7
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
L'essentiel n'est pas dans le testeur, encore une fois ! Pas dans le testeur, mais dans des conditions réelles où l'histoire est téléchargée et où des échecs de connexion se produisent.
Si une réinitialisation et un nouveau calcul de l'indicateur se produisent dans la vie réelle, il n'y a rien de mal à cela.
Une autre question s'est posée. La plupart des gens n'ont-ils pas quelque chose à faire ici ? Ils sont en train de réécrire la fonctionnalité standard du terminal pour mql5. Peut-être que quelqu'un écrira très bientôt un terminal complet sur mql5.
Si, dans des conditions réelles, une réinitialisation et un nouveau calcul de l'indicateur se produisent, il n'y a rien de mal à cela.
Une autre question s'est posée. La plupart des gens n'ont-ils pas quelque chose à faire ici ? Ils sont en train de réécrire la fonctionnalité standard du terminal pour mql5. Peut-être que quelqu'un écrira un terminal entier sur mql5 très bientôt.
Bien sûr, ce n'est pas si mal. Lorsque vous avez 100 ZUP dans un terminal (juste pour l'exemple), c'est OK...
La même question s'est posée. Tout le monde aime parler uniquement de son point de vue, pourquoi ?
Il y a plus d'un indicateur utilisé ici :
L'influence de la fonction IndicatorCount standard est tout simplement mortelle pour elle (je l'ai vérifié personnellement). Et lorsqu'elles sont mises en œuvre sous forme de classes, les discontinuités de communication sont encore plus pures.
P.S. Pour une AM, ce n'est bien sûr pas un gros problème.
Bien sûr, ce n'est pas un gros problème. Lorsque vous avez 100 ZUP dans un terminal (pour vous donner un exemple), ce n'est pas un gros problème...
La même question s'est posée. Chacun aime argumenter uniquement depuis son propre clocher, pourquoi ?
Quelqu'un veut toujours plus que ce qu'il peut supporter. Mais pourquoi autant ?
Le problème de la réinitialisation de l'indicateur peut être résolu avec cinq lignes de code. Rappelez-vous l'heure de la première mesure, si elle a changé, vous devez refaire un calcul complet. Stocke le numéro de la dernière barre, en cas de réinitialisation, continue le recalcul à partir de cette barre et c'est tout.
Je n'ai pas peur d'affirmer du haut de mon propre clocher, sans rien confirmer par des arguments, que mon clocher est correct, point final.
Quelqu'un veut toujours plus que ce qu'il peut supporter. Mais pourquoi autant ?
Vous pouvez contourner le problème de la réinitialisation de l'indicateur avec cinq lignes de code. Rappelez-vous l'heure de la première mesure, si elle a changé, un nouveau calcul complet est nécessaire. Stocke le numéro de la dernière barre, en cas de réinitialisation, continue le recalcul à partir de cette barre et c'est tout.
Je n'ai pas peur de dire du haut de mon clocher, sans rien confirmer par des arguments, que mon clocher est correct et c'est tout.
Ne sois pas si moralisateur. Apprenez non seulement à écouter, mais aussi à entendre les autres.
L'histoire peut changer en cours de route et votre approche tombera en lambeaux. Demandez à Renat ce qu'il en est.
L'erreur dans IndicatorCounted() dans MT4, qui a été corrigée avec mon astuce seulement maintenant, envoyait même les indicateurs correctement écrits à la casse (en particulier ZigZag sur les petits TFs).
Sans parler de votre approche de cette affaire....
Je ne vais même pas discuter avec vous parce que vous avez complètement tort dans cette situation.
Ne soyez pas si sûr de vous. Apprenez non seulement à écouter mais aussi à entendre les autres.
L'histoire peut changer en cours de route et votre approche tombera en lambeaux. Demandez à Renat ce qu'il en est.
L'erreur dans IndicatorCounted() dans MT4, qui n'a été corrigée que maintenant avec mon conseil, envoyait même des indicateurs correctement écrits à la poubelle (en particulier ZigZag sur les petits TF).
Je ne vais même pas discuter avec vous, car vous avez complètement tort dans cette situation.
Ajoutez quelques vérifications supplémentaires au moment de la réinitialisation, pour savoir si le nombre de barres a augmenté, mais que l'heure de la barre n'a pas changé ou que plus d'une barre a été ajoutée.
Quant au fait d'être trop sûr de soi, c'est l'inverse, c'est toi qui es trop sûr de toi, tu es le troisième qui pense être plus cool que MQ.
Ajoutez quelques vérifications supplémentaires au moment de la réinitialisation, pour savoir si le nombre de barres a augmenté mais que l'heure de la barre n'a pas changé ou si plus d'une barre a été ajoutée.
Pour ce qui est de la confiance en soi, c'est le contraire, vous êtes tous trop sûrs de vous, déjà le troisième qui pense être plus cool que MQ.
Quel genre de chèques ? Situation. Une nouvelle coche apparaît sur l'ancienne barre. Rien n'a changé - ni le nombre total de barres, ni l'heure d'ouverture de la dernière barre, mais en même temps
les30 dernières barres ont été réécrites (leurs prix d'ouverture/fermeture, max, min, ont changé, mais de façon insignifiante).
Que ferez-vous de votre algorithme ? Rien ! Cela ne fonctionnera tout simplement pas dans cette situation. Et l'indicateur sera complètement incorrect !
Ce qui était dans MT4 avant les dernières mises à jour - dans 70% des cas, il ne réagirait pas à cette situation.
Mais après avoir analysé le problème, ils l'ont corrigé. Stingo a écrit à ce sujet : https://www.mql5.com/ru/forum/132422.
Je ne pense pas être plus cool que les autres. Au contraire, je participe activement à la correction de tous les bugs de MT4 et MT5 - demandez à n'importe quel représentant de MetaQuotes.
Et le fait que certains mécanismes ne sont pas mis en œuvre comme vous le souhaitez - on ne peut pas plaire à tout le monde.....
Il est intéressant de savoir ce qui est correct, ce qui était avant ou après la correction de l'histoire. Si vous ne revenez pas aux barres corrigées, l'indicateur continuera à fonctionner comme si l'historique n'avait pas été corrigé. Hrenfx a exactement cette attitude, il considère que l'ancienne histoire est correcte, vous avez le contraire.
Il existe également une opinion selon laquelle vous ne devriez utiliser que la version régulière de prev_calculated, sans variations. Si l'indicateur est lourd, limitez le nombre de barres comptées au démarrage. Le reste est une danse de tambourin, le résultat est douteux.
Il est intéressant de savoir ce qui est correct, ce qui était avant ou après la correction de l'histoire. Si vous ne revenez pas aux barres corrigées, l'indicateur continuera à fonctionner comme si l'historique n'avait pas été corrigé. Hrenfx a exactement cette attitude, il considère que l'ancienne histoire est correcte, vous avez le contraire.
Il y a aussi l'opinion selon laquelle vous ne devriez utiliser que le régulier prev_calculated, de manière invariable. Si l'indicateur est lourd, limitez le nombre de barres comptées au démarrage. Le reste est une danse avec tambourin, le résultat est douteux.
Chacun décide pour lui-même ce qui est considéré comme correct et ce qui ne l'est pas. Pour ZigZag, la situation décrite ci-dessus est une véritable catastrophe. Pour MA, il y aura un écart de 0,0001 dans sa valeur...
L'opinion peut souvent être imposée (je ne dis pas qu'elle est mauvaise).
De manière générale, je suggère de mettre fin à la discussion ici. Les raisonnements théoriques ne vous mèneront nulle part.
Dans le testeur, l'optimisation personnalisée des calculs de l'indicateur fonctionnera parfaitement, mais dans le terminal client, elle peut provoquer des décalages désagréables de l'historique et des calculs incorrects.
A propos, mt5 utilise un contrôle très efficace et instantané de l'intégrité de la base historique dans rltime, ce qui augmente la fréquence de remise à zéro de prev_counted. Si vous ne tenez pas compte de ce compteur correctement, et que vous vous occupez de vos propres optimisations, vous risquez de rencontrer de nombreux problèmes dans votre travail réel. Les mises à jour de l'historique des minutes sont instantanément transmises aux terminaux par le serveur lui-même.
Dans le testeur, l'optimisation personnalisée des calculs des indicateurs fonctionnera parfaitement, mais dans le terminal du client, l'historique se déplace et des calculs incorrects peuvent apparaître.
C'est aussi ce que je veux dire.
Peut-être réfléchirez-vous à la manière de remettre prev_counted non pas à zéro, mais à la première valeur inchangée ?