Indicateurs d'élite :) - page 218
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
Mladen,
Merci.
Mladen...
Salut Mladen,
RE : Indicateur de tendance "nonlagma multi time frames".
En regardant la ligne 164, je trouve ce codage:
limit = MathMin(Bars-counted_bars,Bars-1) ;
N'étant pas un codeur, veuillez pardonner mon ignorance.
Ma question est de savoir si cela peut être la raison pour laquelle l'indicateur saute 2 barres en arrière même lorsqu'il est réglé sur 1 TF tel qu'un M30 sur M5-TF ?
Je vois un énorme potentiel pour cet indicateur, à condition que l'on puisse "rectifier" ce problème.
Merci de me répondre après avoir profité du week-end.
Bonne continuation.
ValeoFX
Je dois admettre que je ne comprends pas complètement votre question, mais je vais essayer d'expliquer certaines choses qui, je pense, vous laissent perplexe.
_________________________
Metatrader traite les tableaux comme du C++ : lorsque vous accédez au dernier élément d'un tableau de 10 éléments, vous n'utilisez pas 10 pour l'index de l'élément mais 9. D'où la partie "Bars-1" dans cette expression - pour éviter de sortir des limites du tableau. La première partie (Bars-counted_bars) détermine simplement combien de barres ont effectivement changé et doit être calculée (chaque barre changée doit être recalculée en raison de la modification de l'entrée). Puisque counted_bars peut être 0, cette expression peut donner Bars comme un nombre de barres à calculer, mais alors vient la sécurité "Bars-1".
C'est tout. Elle ne peut pas provoquer de calcul erroné. Elle détermine simplement combien de barres elle doit recalculer (ne tombez pas dans le piège que recalculer est repeindre : ce n'est pas le cas. Comme je l'ai dit à plusieurs reprises, le repeint est une erreur de codage, le recalcul est un état normal d'un code quand avec les mêmes entrées les résultats doivent être les mêmes aussi).
_________________________
Le multi time frame, d'un autre côté, doit être traité avec précaution : il s'agit d'un ensemble de données complètement distinct, d'un nombre de barres modifié complètement distinct, de tout ce qui est distinct. C'est la raison pour laquelle j'appelle le cadre temporel cible pour obtenir le nombre de barres modifiées : sinon, ce ne serait qu'une supposition. Mais lorsqu'un cadre temporel cible est appelé, il renvoie les valeurs que metatrader a assignées et "connaît" pour ce cadre temporel, donc aucune supposition n'est faite. Et lorsque le nombre de barres de tous les cadres temporels est combiné, le résultat le plus long doit être utilisé. Mais, comme vous le savez, une barre d'une heure sur un graphique d'une minute prend jusqu'à 60 barres pour chaque barre d'une heure (je dis "jusqu'à" car des barres dans n'importe quel cadre temporel peuvent manquer), donc le nombre de barres de chaque cadre temporel est multiplié par le ratio qui représente le nombre de barres que le cadre temporel cible occupe sur un graphique actuel.
Donc, vous voyez, cela dépend complètement des "réponses" reçues des cadres temporels cibles (terminal metatrader à la fin) et des calculs des cadres temporels cibles (encore une fois terminal metatrader et le nombre de barres recalculées) Dans mon expérience, metatrader a tendance à diviser certains processus en plus petits "morceaux" : il distribue le temps de traitement entre tous les graphiques et tous les threads qu'il initie et puisque chaque appel personnalisé de trame temporelle est traité comme un indicateur et un thread complètement séparé, il pourrait distribuer ce temps "à sa manière" (pas séquentiellement pour un processus mais séquentiellement pour les threads démarrés, ce qui ne doit pas être du tout dans le même ordre que les processus) et cela pourrait causer quelques "hoquets" lors de calculs massifs - mais pour autant que je sache, cela se stabilise en fin de compte, au final, cela se stabilise et donne des résultats qui sont corrects, sans aucune hypothèse et sans négliger aucune partie du calcul dans son ensemble, ce qui est le but de tout calcul correct
_________________________
J'espère que ce que j'ai dit ici a du sens. Je ne peux pas l'expliquer plus simplement (l'enseignement n'est pas quelque chose que je fais bien
)
Salutations
Mladen
Bonjour Mladen,
RE : Indicateur de tendance "nonlagma multi time frames".
En regardant la ligne 164, je trouve ce codage:
limit = MathMin(Bars-counted_bars,Bars-1) ;
N'étant pas un codeur, veuillez pardonner mon ignorance.
Ma question est de savoir si cela peut être la raison pour laquelle l'indicateur saute 2 barres en arrière même lorsqu'il est réglé sur 1 TF tel qu'un M30 sur M5-TF ?
Je vois un énorme potentiel pour cet indicateur, à condition que l'on puisse "rectifier" ce problème.
Merci de me répondre après avoir profité du week-end.
Meilleures salutations.ValeoFX
Je dois admettre que je ne comprends pas complètement votre question, mais je vais essayer d'expliquer certaines choses qui, je pense, vous laissent perplexe.
_________________________
Metatrader traite les tableaux comme du C++ : lorsque l'on accède au dernier élément d'un tableau de 10 éléments, on n'utilise pas 10 comme indice d'élément mais 9. D'où la partie "Bars-1" dans cette expression - pour éviter de sortir des limites du tableau. La première partie (Bars-counted_bars) détermine simplement combien de barres ont effectivement changé et doit être calculée (chaque barre changée doit être recalculée en raison de la modification de l'entrée). Puisque counted_bars peut être 0, cette expression peut donner Bars comme un nombre de barres à calculer, mais alors vient la sécurité "Bars-1".
C'est tout. Elle ne peut pas provoquer de calcul erroné. Elle détermine simplement combien de barres elle doit recalculer (ne tombez pas dans le piège que recalculer est repeindre : ce n'est pas le cas. Comme je l'ai dit à plusieurs reprises, le repeint est une erreur de codage, le recalcul est un état normal d'un code quand avec les mêmes entrées les résultats doivent être les mêmes aussi).
_________________________
Le multi time frame, d'un autre côté, doit être traité avec précaution : il s'agit d'un ensemble de données complètement distinct, d'un nombre de barres modifié complètement distinct, de tout ce qui est distinct. C'est la raison pour laquelle j'appelle le cadre temporel cible pour obtenir le nombre de barres modifiées : sinon, ce ne serait qu'une supposition. Mais lorsqu'un cadre temporel cible est appelé, il renvoie les valeurs que metatrader a assignées et "connaît" pour ce cadre temporel, donc aucune supposition n'est faite. Et lorsque le nombre de barres de tous les cadres temporels est combiné, le résultat le plus long doit être utilisé. Mais, comme vous le savez, une barre d'une heure sur un graphique d'une minute prend jusqu'à 60 barres pour chaque barre d'une heure (je dis "jusqu'à" car des barres dans n'importe quel cadre temporel peuvent manquer), donc le nombre de barres de chaque cadre temporel est multiplié par le ratio qui représente le nombre de barres que le cadre temporel cible occupe sur un graphique actuel.
Donc, vous voyez, cela dépend complètement des "réponses" reçues des cadres temporels cibles (terminal metatrader à la fin) et des calculs des cadres temporels cibles (encore une fois terminal metatrader et le nombre de barres recalculées) Dans mon expérience, metatrader a tendance à diviser certains processus en plus petits "morceaux" : il distribue le temps de traitement entre tous les graphiques et tous les threads qu'il initie et puisque chaque appel personnalisé de trame temporelle est traité comme un indicateur et un thread complètement séparé, il pourrait distribuer ce temps "à sa manière" (pas séquentiellement pour un processus mais séquentiellement pour les threads démarrés, ce qui ne doit pas être du tout dans le même ordre que les processus) et cela pourrait causer quelques "hoquets" lors de calculs massifs - mais pour autant que je sache, cela se stabilise en fin de compte, en fin de compte, cela se stabilise et donne des résultats qui sont corrects, sans aucune hypothèse et sans négliger aucune partie du calcul dans son ensemble, ce qui est le but de tout calcul correct
_________________________
J'espère que ce que j'ai dit ici a du sens. Je ne peux pas l'expliquer plus simplement (l'enseignement n'est pas quelque chose que je fais bien
)
Salutations
Mladen=================
Je m'incline devant votre savoir supérieur, SIR !
Merci d'avoir pris le temps de m'enseigner une précieuse leçon. J'apprécie beaucoup.
Je vous souhaite une excellente semaine à venir.
Bonjour mladen
Pourriez-vous faire une version histo de l'indicateur non flagdot ?
très apprécié
Merci.
Mike
VoilàMladen
Pourriez-vous s'il vous plaît faire une version histo de l'indicateur non flagdot...
très apprécié
merci.MERCI MLADEN
indicateur non flagdot
J'ai une requête.
Au lieu d'avoir des points partout sur le graphique, est-il possible de dessiner une flèche vers le haut/bas lorsque la couleur change sans dessiner les points ?
Cela laisse le graphique beaucoup plus propre et, à mon humble avis, c'est beaucoup plus utile pour essayer de l'évaluer dans un backtasting "à l'œil".
Est-ce que cet indicateur se repeint ?
Merci d'avance,
Dada.
Comme je le sais, il ne repeint pas...
Bonjour mladen
Mike
Voilà
J'ai supprimé le ColorBarBack (ce paramètre n'est pas nécessaire du tout - le redessin de cette façon était un vestige d'un mode de dessin au trait (pas le dessin au point)). Salutations MladenJ'ai besoin de te demander encore une faveur
VERSION HISTO de Averages-mtf-alerts
Merci pour votre temps et votre patience