Non conservation de la valeur d’une variable en MTF

Viewing 15 posts - 1 through 15 (of 23 total)
  • Author
    Posts
  • #255450 quote
    StephC
    Participant
    New

    Bonjour,

    Je me retrouve confronté à une problématique/beug avec le Multi-Time-Frame.
    J’ai codé quelques indicateurs qui sont spécifiques à un TimeFrame (graphique avec une unité de temps choisie) par exemple : l’indicateur 1 est pour un TimeFrame de 10Min, l’indicateur 2 pour un TimeFrame de 1Min,…

    A l’heure actuelle, je souhaite regrouper ces indicateurs (leur code) dans un graphique avec une unité de temps de 10s. Mais lorsque je commence à le faire avec le code de l’indicateur en 10Min dans le graphique en 10s, j’ai un comportement de ce code différent de celui qu’il a dans le graphique 10Min. Et la raison est que je n’ai pas une conservation de la valeur d’une variable dans une condition ‘IF’.

    J’ai réussi à reproduire le problème avec un code simple à utiliser dans un graphique en 10s :

    TIMEFRAME(10 MINUTES)
    // signal 0 ou 1 toutes les 10Min
    signalActif = 0
    IF OpenTime MOD 2000 = 0 THEN
    signalActif = 1
    ENDIF
    // signalOnTF10Min = 2 lors de la première activation du signal et reste égal à 2 (conservation de la valeur précédente)
    IF signalActif THEN
    signalOnTF10Min = 2
    ENDIF
    // signalOffTF10Min = 3 lors de la première dé-activation du signal et reste égal à 3 (conservation de la valeur précédente)
    IF NOT signalActif THEN
    signalOffTF10Min = 3
    ENDIF
    
    // signalOnTF10MinDelta1Bougie = 10 lors de la fin de la première dé-activation du signal et NORMALEMENT reste égal à 10 (conservation de la valeur précédente)
    IF NOT signalActif[1] THEN
    signalOnTF10MinDelta1Bougie = 10
    ENDIF
    
    // signalOnTF10MinDelta1Bougie = 12 lors de la première activation du signal et quand à la bougie précédente le signal n'est pas actif et NORMALEMENT reste égal à 12 (conservation de la valeur précédente) ?! Mais c'est pas le cas...
    IF signalActif AND NOT signalActif[1] THEN
    signalOnEtonActifBougiePrecedenteTF10Min = 12
    ENDIF
    
    TIMEFRAME(DEFAULT)
    // si le signal est actif alors estSignalActifTF10s = 4 sinon il repasse à 0
    estSignalActifTF10s = 0
    IF signalActif THEN
    estSignalActifTF10s = 4
    ENDIF
    // conservation de la valeur avec le premier passage du signal actif
    IF signalActif THEN
    conservationValeurTF10s = 5
    ENDIF
    
    IF signalActif AND NOT signalActif[1] THEN // Comportement attendu = conservation de la valeur
    signalOnEtonActifBougiePrecedenteTF10s = 15
    ENDIF
    
    RETURN signalActif AS "signalActif" COLOURED(0,0,160,255) STYLE(HISTOGRAM), estSignalActifTF10s AS "estSignalActifTF10s" COLOURED(250,128,192,100) STYLE(HISTOGRAM), signalOnTF10Min AS "signalOnTF10Min" COLOURED(0,255,0,100) STYLE(HISTOGRAM), signalOffTF10Min AS "signalOffTF10Min" COLOURED(255,0,0,100) STYLE(HISTOGRAM), conservationValeurTF10s AS "conservationValeurTF10s", signalOnTF10MinDelta1Bougie AS "signalOnTF10MinDelta1Bougie", signalOnEtonActifBougiePrecedenteTF10Min AS "signalOnEtonActifBougiePrecedenteTF10Min" COLOURED(255,255,0,100) STYLE(HISTOGRAM), signalOnEtonActifBougiePrecedenteTF10s AS "signalOnEtonActifBougiePrecedenteTF10s

    Pour toutes les conditions ‘IF’, il y a conservation de la valeur de la variable sauf pour le cas du “IF signalActif AND NOT signalActif[1] THEN” où dans le TimeFrame de 10 minutes la variable prend la bonne valeur mais que pour une bougie de 10s quand la condition est réalisée alors qu’elle devrait conservée sa valeur comme dans le TimeFrame(Default) où la même condition “IF signalActif AND NOT signalActif[1] THEN” permet d’avoir la bonne valeur lors du premier passage dans le IF et de la conserver.

    Est-ce un beug ou moi qui n’est pas réellement compris le MultiTimeFrame ?

    Merci,

    Cordialement,

    Stéphane CAU

    #255451 quote
    JS
    Participant
    Senior

    Salut,

    Tu as essayé ça… ?

    TimeFrame(10 minutes, UpdateOnClose)

    Iván González thanked this post
    #255455 quote
    StephC
    Participant
    New

    Salut,

    Oui, la valeur de “signalOnEtonActifBougiePrecedenteTF10Min” est conservée avec UPDATEONCLOSE. Mais dans mon cas, ce n’est pas le but d’avoir le calcul à la fermeture de la bougie de 10min. J’ai un décalage égal à la durée de la bougie que je ne souhaite pas.

    Après, ce que je veux n’est peut-être pas possible, mais cela me parait bizarre que dans ce cas cela ne marche pas. Pourquoi les autres conditions dans le TimeFrame 10Min sans UPDATEONCLOSE conservent leur valeur.

    La condition où cela ne marche pas est “juste la somme” des deux conditions des lignes 8-10 et 17-19 qui marchent elles.

    J’ai l’impression que le ‘[1]’ de ‘NOT signalActif[1]’ dans le TIMEFRAME 10MIN fait appel à la valeur du TIMEFRAME par DEFAUT dans mon cas 10seconde. Mais je n’ai pas de condition pour changer la valeur à partir du moment où ‘IF signalActif AND NOT signalActif[1] THEN’ a été vrai une fois donc elle ne devrait pas changer à mon avis. Comme pour la même condition mais dans le timeframe 10s (celui par défaut) qui est aux lignes 37-39 de mon code.

    Afin bref, il est un peu tard, je suis peut-être un peu trop fatigué pour comprendre et surtout, j’ai passé trop de temps aujourd’hui sur le fait d’essayer de comprendre les différences de comportement entre mon indicateur dans le graph 10min et le même code mais dans un timeframe de 10min dans un graph de 10s…

    #255456 quote
    JS
    Participant
    Senior

    Le problème avec ton code est que les différents signaux ne sont jamais réinitialisés…

    Lorsque, par exemple, tu dis :

    If signalActif then

    signalOnTF10Min = 2
    EndIf

    Lorsque signalActif a été vrai une seule fois, le signal signalOnTF10Min = 2 reste toujours vrai parce qu’il n’est pas réinitialisé…

    If signalActif then

    signalOnTF10Min = 2
    Else
    signalOnTF10Min = 0
    EndIf
    La même chose s’applique aux autres signaux…
    Iván González and Nicolas thanked this post
    #256529 quote
    AI-vy
    Moderator
    New

    Ce n’est pas un bug : en MultiTimeFrame sans UpdateOnClose, le bloc TIMEFRAME(10 MINUTES) est réévalué à chaque bougie du timeframe par défaut (ici 10s) avec une bougie 10 minutes “en cours”. Dans ce mode, les séries du TF 10min peuvent changer/invalider leurs états tant que la bougie 10min n’est pas clôturée.

    Du coup, le test signalActif AND NOT signalActif[1] (détection de “front montant”) est instable en intrabar :

    • signalActif peut passer à 1 puis revenir à 0 (ou l’inverse) tant que la bougie 10 minutes n’est pas finalisée (selon ta condition basée sur OpenTime MOD … et le recalcul).
    • signalActif[1] ne représente pas “la bougie 10 minutes précédente clôturée” mais la valeur de la série au pas de calcul précédent (une itération 10s plus tôt), donc ton “front” est recalculé et peut ne pas rester vrai/figé.

    Pourquoi tes autres IF “semblent” conserver ? Parce que :

    • IF signalActif THEN x=2 ne dépend pas d’un état précédent ([1]), donc dès qu’il a été vrai une fois, tu observes une “persistance” simplement parce que tu ne réinitialises jamais la variable (elle garde sa dernière valeur affectée).
    • En revanche, un test de transition AND NOT …[1] est, lui, un événement (1 seule fois), et en intrabar MTF l’événement peut être “rejoué/annulé” pendant la construction de la bougie 10min.

    Solution ProRealTime (recommandée) : figer l’événement sur clôture du TF supérieur

    • Si tu veux un “front montant” fiable du TF 10 minutes, il faut travailler sur des valeurs clôturées du TF 10 minutes, donc UpdateOnClose.
    • Ensuite, tu peux reporter cette information sur le 10s sans décalage de visualisation en stockant un état et en l’affichant sur le TF par défaut.

    Exemple robuste : on calcule le front en 10 minutes clôturées, puis on le propage en 10 secondes.

    // — TF 10 minutes : calcul “stable” uniquement à la clôture —
    TIMEFRAME(10 MINUTES, UpdateOnClose)
    
    // 0/1 toutes les 10 minutes (exemple)
    signalActif = 0
    IF OpenTime MOD 2000 = 0 THEN
     signalActif = 1
    ENDIF
    
    // Front montant “propre” (sur bougies 10min clôturées)
    frontOn10m = signalActif AND NOT signalActif[1]
    
    TIMEFRAME(DEFAULT)
    
    // Propagation sur le TF 10s : on fige la dernière valeur
    IF frontOn10m THEN
     signalOnEtonActifBougiePrecedenteTF10Min = 12
    ENDIF
    
    RETURN signalActif AS “signalActif_10m”, frontOn10m AS “frontOn10m”, signalOnEtonActifBougiePrecedenteTF10Min AS “memoFront”

    Pourquoi ça marche : UpdateOnClose garantit que signalActif et signalActif[1] correspondent à deux bougies 10 minutes clôturées, donc le front montant est déterministe. Ensuite, sur le TF 10s, tu ne fais que mémoriser l’événement (variable non réinitialisée), ce qui donne l’effet “conservation”.

    Point clé : vouloir à la fois (1) un calcul MTF “comme si on était sur le graphique 10 minutes” et (2) sans attendre la clôture 10 minutes est contradictoire pour tout ce qui dépend de [1] (détection d’événements), car la bougie 10 minutes n’est pas finalisée et ses états peuvent être recalculés à chaque 10 secondes.

    StephC thanked this post
    #256595 quote
    StephC
    Participant
    New

    Bonjour,

    Merci beaucoup Al-vy pour cette très bonne explication technique. J’ai dû reformater un peu mon cerveau avec ces informations plus précises sur le MTF 😉.

    Si je résume ce que j’ai compris :

    En MULTITIMEFRAME, avec une unité de temps plus grande (10 MIN dans mon cas) et sans UPDATEONCLOSE, le bloc de code lié à la bougie active est actualisé selon l’unité de temps par défaut. C’est finalement assez logique sans UPDATEONCLOSE.

    Concrètement, pour mon test de front montant, la condition est vraie uniquement pendant les 10 premières secondes (unité de temps par défaut), puis elle redevient fausse. De plus, il n’y a pas de persistance de la valeur de la variable tant que la bougie n’est pas clôturée, puisque son état ne se fige qu’à la clôture.

    Je me suis un peu fait piéger lors de mes vérifications. Pour confirmer que AND NOT ...[1] faisait bien référence à la bougie 10 MIN clôturée précédant celle active, et qu’il y avait bien persistance de la valeur, j’ai utilisé des PRINTs sur BarIndex[1] ou OpenTime[1]. Ces valeurs correspondent bien à la bougie 10 MIN clôturée précédente avec persistance.

    En revanche, je n’avais pas fait de PRINT directement sur "NOT ...[1]".

    Sur l’image jointe (capture des résultats des PRINTs), on voit clairement le basculement de la condition "NOT ...[1]" au bout de 10 secondes.

    Je m’étais donc arrêté à une vision simplifiée :

    le bloc de code dans le timeframe 10 minutes se comporte comme l’indicateur affiché sur un graphique 10 min

    en oubliant la particularité de la bougie active, qui n’a pas encore de persistance de valeur.

    La détection du front montant reste vraie sur un graphique 10 minutes, contrairement à un graphique 10 s avec un TIMEFRAME 10 minutes.

    Du coup, je suis un peu bloqué sur la méthode à adopter pour mon cas concret.

    Cas d’usage

    Je travaille sur le marché américain en horaires étendus, mais je souhaite initier certains calculs de variables uniquement sur des plages spécifiques, par exemple pendant la session officielle de 9 h 30 à 16 h (heure US).

    J’ai créé mes indicateurs sur différents graphiques :

    • 10 min
    • 5 min
    • 1 min
    • 10 s

    Je souhaiterais maintenant regrouper l’affichage de certaines variables dans le graphique 10 s.

    Cependant, en reprenant simplement le code de chaque unité de temps supérieure dans un TimeFrame adapté au graphique 10 s, je n’obtiens pas les mêmes valeurs.

    L’utilisation de UPDATEONCLOSE donne bien les bonnes valeurs, mais avec un décalage correspondant à l’unité de temps du TimeFrame (par exemple 10 minutes pour un TimeFrame 10 MIN). Or, entre 9 h 30 et 9 h 40, il peut se passer beaucoup de choses sur le marché américain.

    Il me semble avoir lu que l’utilisation du backtest en temps réel permettait de regrouper des indicateurs de différentes unités de temps. Mais cela ne serait donc pas possible en dehors du backtest, sauf avec UPDATEONCLOSE ?

    Bref, ma méthode initiale n’était pas la bonne.

    Merci encore pour cette explication détaillée sur ce comportement en MULTITIMEFRAME.

    Je vais continuer à chercher une solution et je reviendrai la partager ici si j’en trouve une.

    Sachant que le code qui pose problème en gros est :

    debutTradingPeriode = 93000
    debutPostOuverture = 160000
    /*---------------------------------------------------------------*/
    // Activation et compteur de la période de Trading
    estTradingPeriode = 0
    IF OpenTime >= debutTradingPeriode AND OpenTime < debutPostOuverture THEN
    estTradingPeriode = 1
    compteurPeriodeTrading = compteurPeriodeTrading[1] + 1
    ENDIF
    /*---------------------------------------------------------------*/
    // Compteur du nombre de bougie intraday
    ONCE compteurOpenDay = 1
    IF OpenDay <> OpenDay[1] THEN
    ONCE est1erJourEntier = -2
    est1erJourEntier = est1erJourEntier + 1
    compteurOpenDay = 1
    IF NOT estTradingPeriode THEN
    compteurPeriodeTrading = 0
    ELSE
    compteurPeriodeTrading = 1
    ENDIF
    ELSE
    compteurOpenDay = compteurOpenDay + 1
    ENDIF
    /*---------------------------------------------------------------*/
    // Compteur du nombre de bougie depuis le début de la période : permet d'obtenir une valeur à la cloture de la période précédente par exemple
    IF BarIndex > 0 THEN
    compteurOpenTrading = 0
    IF estTradingPeriode AND NOT estTradingPeriode[1] THEN // C'est ici que cela ne marche plus et du coup les calculs par la suite utilisant 'compteurOpenTrading' sont faux
    compteurOpenTrading = 1
    ELSE
    compteurOpenTrading = compteurOpenTrading[1] + 1
    ENDIF
    ENDIF
    /*---------------------------------------------------------------*/
    
    #256603 quote
    Nicolas
    Keymaster
    Master

    J’ai reformaté tes posts, et supprimé ceux inutiles (repost) ; désolé pour ce désagrément, je pensais l’avoir corrigé 🙂

    Pourrais-tu m’indiquer comment tu as poster tes derniers messages stp ?

    #256606 quote
    StephC
    Participant
    New

    Bon en fait il faut un certain temps, une fois le post écrit pour qu’il apparaisse sans les balises html.

    Sinon, pour information, pour que le compteur marche, j’ai modifié la condition ” IF estTradingPeriode AND NOT estTradingPeriode[1] THEN par :

    IF OpenTime >= debutTradingPeriode AND OpenTime[1] < debutTradingPeriode THEN
    

    Après, peut-être que ce n’est pas justifié et utile de faire cela et que UPDATEONCLOSE est la bonne pratique…

    #256607 quote
    Nicolas
    Keymaster
    Master

    Non, je vois toujours des balises dans ton message 🙁

    Pourrais tu stp faire un refresh complet de la page ? CTRL+F5 et retenter un post, merci ! (désolé encore pour le débugging …)

    #256608 quote
    StephC
    Participant
    New
    <p>Ah ok, je pense que j’ai cliqué au départ sur le bouton “reply” de la réponse de Al-vy.</p><p>Puis j’ai écrit mon texte.</p><p>Ensuite, le trouvant pas top, j’ai fait un copier/coller de mon texte vers ChatGPT pour qu’il reformule un peu et j’ai copié/collé sa réponse à la place de mon texte.</p>
    #256609 quote
    StephC
    Participant
    New
    <p>Je suis sur une nouvelle fenêtre, pour voir…</p>
    #256610 quote
    StephC
    Participant
    New
    <p>Je suis sur Mac OS, j’ai fait un Cmd+R et j’ai ouvert une nouvelle fenêtre chrome avec uniquement un seul onglet.</p>
    #256611 quote
    Biloute62
    Participant
    Junior
    <p>Je veux bien vous aider à tester, ça donne quoi ?</p><p>Une autre ligne </p>
    #256612 quote
    StephC
    Participant
    New
    <p>Après un logout et une nouvelle fenêtre</p>
    #256613 quote
    Nicolas
    Keymaster
    Master

    Merci mais le problème est côté serveur. Je vais push un update.

Viewing 15 posts - 1 through 15 (of 23 total)
  • You must be logged in to reply to this topic.

Non conservation de la valeur d’une variable en MTF


Support ProBuilder

New Reply
Author
author-avatar
StephC @stecoapps Participant
Summary

This topic contains 22 replies,
has 5 voices, and was last updated by StephC
11 hours, 43 minutes ago.

Topic Details
Forum: Support ProBuilder
Language: French
Started: 01/19/2026
Status: Active
Attachments: 1 files
Logo Logo
Loading...