indicateurs MTF pour ProRealTime disponible ! – programmation MTF pour ProBuilder
- This topic has 40 replies, 14 voices, and was last updated 3 months ago by
.
-
J’arrive à reproduire l’erreur, je me charge de remonter le problème, merci de l’avoir signalé.
1 user thanked author for this post.
Pour avoir des marches d’escalier, il faut utiliser updateonclose. Exemple :
TimeFrame (2 hours, updateonclose)
Et une moyenne exponentille utilise quasiment toutes les données de l’historique vu sa définition. Difficile de voir si les calculs sont identiques ou pas entre un mtf 1h affiché en 1 minute, et sur un graphique en un affichage 1 heure, les resultats sont proches avec 1000 ut 1h et 60000 ut 1 minutes, bien que ce soit qu’une extrapolation non rigoureuse. On peut ajouter un test pour le savoir à partir du compteur de bars affichées en timeframe 1 heure sur le graphique 1 minute. Je l’ai fait quelque part sur prorealtime dans ce forum.
1 user thanked author for this post.
Merci Ginko,
J’ai retesté en faisant plus simple avec:
EH = Average[8*60](close)
TIMEFRAME(1 hour )
E1 = Average[8 ](close)TIMEFRAME(1 hour, updateonclose)
E11 = Average[8 ](close)TIMEFRAME(default)
return EH coloured(255,50,50) as “EH”, E1 coloured(155,160,10)as “E1”,E11 coloured(255,160,10)as “E11”
Les marches d’escalier sont propres avec “updateonclose”.J’aimerais bien connaitre l’algorithme qui fait que les deux graphiques, avec ou sans “updateonclose”, ne se ressemblent pas plus;
Il y a un décalage vertical systématique d’une hauteur de marche, l’un commence là où l’autre finit…
Et puis je ne comprends pas l’origine de ce bruit “haute fréquence” surajouté aux paliers des marches.
De cette nouveauté MTF, j’espérais surtout bénéficier des informations qui correspondent aux différents “timeframe” , je veux dire que à l’unité de temps d’une minute pour beaucoup de titre on n’a pratiquement pas d’historique alors qu’à “1h” la profondeur de l’historique augmente considérablement. Or de changer de time frame dans les calculs des indicateurs, ne change pas l’historique de base , et à une minute si l’on a rien, timeframe ou pas, on a toujours rien… (sur certaines valeurs, quand on a pas une version premium).
Dans des cas simples , comme une moyenne mobile, autant ne pas changer des “timeframe” et se contenter d’augmenter la période , au moins c’est lissé comme on le souhaite.
Il y a cependant sans doute des cas où il ne suffit pas de faire x60 et où le “timeframe 1H” devient indispensable… Mais entre nous je suis un peu déçu…
A propos de #175910, il n’y a pas d’historique en plus avec le MTF. J’espérais la même chose quand c’est sorti, mais vu que ce n’était pas le cas, j’ai gardé une émulation-maison MTF d’avant-sortie que je n’aurai remplacée qu’en cas d’accès à un historique accru.
J’aimerais bien connaitre l’algorithme qui fait que les deux graphiques, avec ou sans “updateonclose”, ne se ressemblent pas plus;
Il y a un décalage vertical systématique d’une hauteur de marche, l’un commence là où l’autre finit…
Dans le MTF de la plateforme, l’updateonclose utilise la clôture précédente de l’ut supérieure sur les bougies d’ut inférieure internes à la bougie de l’ut supérieure en cours, donc pendant tout le développement de la bougie en cours d’ut supérieure cela donne ce que tu appelles une “marche d’escalier” (puisque la valeur reste fixe) qui ne passera à la marche suivante qu’à la première bougie d’ut inférieure qui suivra la nouvelle clôture d’UT supérieure. Sans l’updateonclose, la dernière valeur prise pour l’ut supérieure est le dernier prix courant, ce que tu appelles “bruit” à la place d’une marche correspond au calcul fluctuant avec le parcours intégral du prix entre open et close de la bougie en cours de l’UT supérieure.
Pour revenir sur le post #175849, ce qui marche assez bien dans des cas équipondérés (mm simple, faire période “PER” de l’utsup x60 pour 1h sur 1mn, avec chacune des 60xPER ayant un poids égal) ne marche de toute façon pas dans des cas où la pondération varie (mm exp). En effet mm exp = poids plus gros sur dernière bougie, et poids plus gros sur la toute dernière “petite bougie de PERx60 bougies en petite ut”, s’éloignera trop du calcul avec poids plus gros sur dernière “grosse bougie de PER bougies” en grande UT.
1 user thanked author for this post.
Pojr l’historique, j’avais posé la question sur le forum anglais, et j’avais eu une réponse pour le backtest et les stratégies.
Rien sur les graphiques de base, sinon changer le nombre de barres affichées. Cf https://www.prorealcode.com/topic/multi-timeframe-mtf-indicators-for-prorealtime/page/4/#post-166630
Pour les strategies, c’est le paramètre preloadbars
https://www.prorealcode.com/documentation/preloadbars/
Ensuite pour vérifier les valeurs, je faisais un graphonprice qui fonctionne.
L’intérêt c’est qu’alors je peux calculer un indicateur mtf H1 sur un graphique en 1 minute avec beaucoup d’historique : tout en n’affichant que 2000 barres m1, mais en calculant sur 1000 barres h1 par exemple.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
