indicateurs MTF pour ProRealTime disponible ! – programmation MTF pour ProBuilder

Forums ProRealTime forum Français Support ProBuilder indicateurs MTF pour ProRealTime disponible ! – programmation MTF pour ProBuilder

Currently, there are 0 users and 1 guest visiting this topic.
View all attachments
Viewing 15 posts - 16 through 30 (of 35 total)
  • #167724 Report

    Quand on déclare une variable codée pour un indicateur H4 dans un graphique H1 par exemple :

    Once constH4=9

    Faut-il la déclarer sur le timeframe default ou dans le timeframe H4 ?

    Que je fasse l’un ou l’autre ne change rien j’ai le même problème :

    J’ai simplifié le code pour reproduire :

    Le workaround est de ne pas mettre once mais je ne sais pas si avec un code plus complexe, je ne vais pas écraser d’autres variables.
    J’ai remarqué aussi que si je ne fais pas appel au SAR, cela se passe nettement mieux…

     

    Attachments:
    #167726 Report

    Et ce n’est pas spécifique au SAR. Si je fais appel à un indicateur autre (comme ici une moyenne de base), je retrouve le même problème

     

     

    Attachments:
    #167751 Report

    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.
    #167818 Report

    Encore un autre problème de calcul cette fois sur un graphique M15 avec 2 indicateurs qui devraient donner exactement le même résultat puisque je choisis le Close pour le (customclose) :

    Le problème est identique pour Typicalprice en sélectionnant Typical pour le CustomPrice.

    Les valeurs  affichées sont très différentes (voir les graphiques joints).

    Est-ce aussi un bug ?

    Attachments:
    #167836 Report

    Si tu utilises le TF 240 minutes, il sera très différent du H4, 240 minutes glissantes, ça n’est pas le TF officiel H4, tu devrais modifier tes déclarations et refaire des tests stp, afin de vérification. Merci.

    #167896 Report

    Nicolas, J’ai refait le test et je reproduis le même problème.

    Le Customclose ne fonctionne pas correctement avec des indicateurs en MTF utilisant (updateonclose). Typiquement graphique en UT 15 minutes et  timeframe (4 hours, updateonclose). -> Bug ?

    Test :

    1/ Timeframe (4 hours) ou timeframe (240 minutes)  donnent le même résultat dans un indicateur. J’ai exactement le même problème. Comme j’ai assigné le Customclose sur le prix de clôture dans ce test, le résultat attendu est le même, mais ils sont très différents. Je pense que le CustomClose n’est jamais correct en MTF avec un updateonclose.

    Code :

     

    2/ Pourrais-tu me préciser comment Prorealtime fonctionne dans un indicateur en MTF ? Pour moi il n’y a pas de différence entre un timeframe 240 minutes et un timeframe 4 hours.

    J’ai fait un test sur un probacktest sur la base du même code en timeframe (4 hours, updateonclose) pour le calcul du RSI. Extrait du code RSI dans le probacktest :

    TimeFrame (240 minutes, updateonclose) //
    once periodRSIH4=14
    RsiH4=RSI[periodRSIH4](close)

    Timeframe (default)
    //Autre code//
    graph RsiH4 COLOURED (0,175,240) as “RsiH4”

    J’ai mis 1/ et 2/ sur 2 graphiques, un en UT 4 hours et l’autre en UT M15  (MTF13.jpg).

    Conclusion, il y a un problème avec customclose et avec un timeframe (4 hours, updateonclose) : les résultats en utilisant Customclose sont incorrects. -> Bug ?

    En fait, cette différence disparait si j’enlève le updateonclose.

     

    TimeFrame (240 minutes)
    once periodRSIH4=14
    RsiH4=RSI[periodRSIH4](close)
    RsiTpH4=RSI[periodRSIH4](TypicalPrice)

    // (Code)

    TimeFrame (default)

    // (Code)
    graph RsiH4 COLOURED (0,175,240) as “RsiH4”

    résultat dans MTF14.err

     

    Attachments:
    #167909 Report

    Si tu utilises le TF 240 minutes, il sera très différent du H4, 240 minutes glissantes, ça n’est pas le TF officiel H4, tu devrais modifier tes déclarations et refaire des tests stp, afin de vérification. Merci.

    C’est une bêtise, après vérification, la plateforme utilise bien une réinitialisation à date, pour coller à l’UT supérieure (comme pour un trimestre = 3 months, commencera toujours en Janvier, 240 minutes commencera toujours à l’heure 00:00).

    Je vais reboucler au sujet du CustomClose, c’est embêtant 🙄

    #168034 Report

    Concernant ce post: https://www.prorealcode.com/topic/indicateurs-mtf-pour-prorealtime-disponible/page/2/#post-167724

    Je vois 2 problèmes, le premier et le plus important c’est que tu déclares une variable dans un timeframe, puis tu lui affectes une autre valeur dans un autre TF.

    Les variables sont historisées dans le TIMEFRAME dans lequel elles sont affectées (ce qui est le but de l’instruction TIMEFRAME). Pour que ce soit cohérent :

    • On interdit la définition de la même variable dans plusieurs TIMEFRAME d’UT/mode différents,

    Donc tu ne peux pas définir la variable dans le timeframe principal puis la redéfinir dans le timeframe secondaire.

    Pour le deuxième problème, puisque tu affectes 0 à la variable dH4, il est logique qu’à la bougie suivante, ton instruction DEMA te flash cette erreur de période nulle (ligne 20).

    #175849 Report
    yj

    Bonjour tous,

    je viens de découvrir cette nouvelle possibilité offerte par PRT, qu’est le “MTF”.

    J’ai donc essayé et je ne comprends pas bien le résultat.

    J’ai comparé trois moyennes exponentielles pour l’unité de temps d’une minute.

    1. La première sans modifier le timeframe pour la période 8*60 en pensant que ce serait à peu de chose près comme 8 périodes d’une heure avec le timeframe à “1 hour”.
    2. La deuxième après avoir mis le time frame à 1h, pour 8 unité de temps.
    3. La troisième après avoir mis le time frame à 2h, pour 8 unité de temps.

    Je m’attendais à des marches d’escalier d’une heure ou deux, ou mieux à une ligne brisée, mais pas à ce que l’on voit apparaitre.

    Il a des  marches d’escaliers et entre chaque marche des calculs intermédiaires que je ne comprends pas…

    Est-ce “normal” ?  Qu’en pensez-vous?

    yj.

    P.S. des copies d’écran des quelques lignes de code, de la configuration définissant les couleurs, et du graphique qui en résulte.

     

    Attachments:
    #175851 Report
    yj

    Je me suis trompé en insérant les images, je recommence:

    Le code:

    MTF_prg

    La configuration:

    MTF_conf

    Le graphique qui en résulte:

    MTF_Res-1

    Attachments:
    #175860 Report

    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.
    avatar yj
    #175910 Report
    yj

    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”

    MTF_tst
    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…

    Attachments:
    #175915 Report

    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.
    avatar yj
    #175919 Report

    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.
    avatar yj
    #175940 Report
    yj
Viewing 15 posts - 16 through 30 (of 35 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login