Discussion de l'article "Graphique Liquide" - page 3
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
Avez-vous réussi à trouver la cause ?
J'ai essayé de faire de mon mieux pour contribuer, peut-être que cela aidera à trouver l'erreur. Sur les photos prises à différents moments, vous pouvez voir comment le graphique de l'indicateur se déplace par rapport au graphique principal.
Il me semble que la raison est qu'au début de chaque semaine il y a une bougie supplémentaire, qui s'accumule et décale le graphique chaque semaine, ceci est valable pour le graphique journalier avec la base H1. Vous pouvez faire un écran le week-end et en début de semaine, ce sera plus clair.
En effet. A certaines valeurs du décalage, des "barres fantômes" apparaissent - pour plus de détails, voir la fig. 4 de l'article, la raison de leur apparition y est également décrite. Comme elles apparaissent à la jonction des semaines, elles sont plus visibles sur les échelles de temps supérieures. En particulier sur le graphique journalier (comme dans votre exemple), parce que l'écran affiche une plage de temps de plusieurs semaines, et avec chaque semaine le décalage est de plus en plus visible.
Il ne s'agit pas d'un bogue, mais d'une fonctionnalité. Vous pourriez éliminer les "barres fantômes", mais cela entraînerait une perte de données, ce qui n'est pas une bonne chose. L'idéal serait de décaler le graphique original à ces endroits, mais vous n'avez pas cette possibilité. Si la synchronisation du graphique initial et du graphique résultant est essentielle pour vous, vous pouvez filtrer les barres "supplémentaires" renvoyées par la fonction GetRatesLC() juste avant de les copier dans la mémoire tampon de l'indicateur.
J'ai fait la même chose. Cela semble fonctionner pour moi sans aucune barre fantôme.
Comme je ne peux pas analyser le code source dans son intégralité, je n'ai rencontré que des choses étranges (à mon avis) en surface.
Tout d'abord, j'ai vu à plusieurs endroits la construction tO-=PeriodSeconds(). Je ne suis pas sûr que l'on puisse procéder ainsi, car en soustrayant PeriodSeconds de t0, on peut atteindre la barre précédente. L'essentiel de la situation lorsque t0 est hors limites est que cette barre liquide n'a pas encore commencé à se former et qu'il n'est pas nécessaire d'essayer d'en déplacer artificiellement le début d'une période.
Deuxièmement, l'heure de clôture ne doit pas être déterminée par le nombre - combien de barres de base peuvent théoriquement entrer dans la période actuelle par rapport à l'ouverture, mais individuellement pour chaque barre de la période actuelle, prenez son heure d' ouverture, prenez l'heure d'ouverture de la barre suivante, pour la seconde cherchez une barre de la période de base et lisez la barre précédente dans la période de base - ce sera la fin de la barre de liquidité.
Pourquoi ai-je besoin de cela ? Je veux voir ce que les Américains, les Australiens, les Japonais, etc. voient sur les graphiques journaliers. Puisque l'heure terminale est différente pour chacun, l'heure de formation d'une bougie journalière est différente pour chacun, et donc l'image sur les graphiques journaliers est différente pour chacun. En ayant la possibilité d'observer la situation dans différents fuseaux horaires, il y a plus d'opportunités de ne pas manquer le bon moment d'entrée. Et si nous n'essayions pas de soustraire le temps du tick nécessaire en soustrayant le temps de décalage du temps d'une barre prédéterminée. Prenons le temps GTM comme point de référence, soustrayons le temps de décalage de ce temps et le premier tick qui vient après ce temps ira former une nouvelle bougie et en conséquence le tick qui vient avant ce temps sera le dernier tick de la bougie précédente. C'est le même principe que pour la formation d'un graphique régulier, si l'heure terminale est 00:00, peu importe quand le premier tick arrive, ce sera toujours le premier tick d'une nouvelle bougie.