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

Viewing 10 posts - 31 through 40 (of 40 total)
  • #175941
    yj

    Désolé pour ces couleurs dans ma réponse précédente, je ne sais pas d’où elles viennent. Enfin si , j’ai fait un copié collé depuis un autre éditeur…

    A éviter donc…  yj.

    #175946
    yj

    C’est illisible; je recommence en espérant que… :

    @ JC_Bywan : Donc si j’ai bien compris la variation pendant la première minute du graphe “non update” est égale à la variation du cours qui a eu lieu entre -7h et -6h avant.
    Ensuite mon “bruit” c’est exactement la variation du cours divisée par 8 dans le cas de average(8).
    Donc ce bruit qui attire l’œil est constitué par des “accidents” d’une minute, correspondant à ce qui s’est passé 7-8 heures avant, accidents qui se poursuivent par une image atténuée du cours évoluant minute par minute.
    Quelle salade somme toute…

    @ Ginko : je ne maîtrise pas assez PRT pour comprendre ce que signifie:
    “je faisais un graphonprice qui fonctionne.”
    J’ai l’impression qu’il s’agit d’une astuce permettant de:
    “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.”
    Si c’est bien ça, cela m’intéresserait beaucoup mais cela reste mystérieux pour moi…

    Merci pour vos réponses soigneuses. yj.

    #176009

    Je ne suis pas sûr de te suivre avec les -6h et -7h, je vais le formuler autrement pour décrire les 2 modes de calculs via le 1h et le 1mn:

    – avec “updateonclose”, pour une moyenne simple de période 8 en grande UT 1h, ce que tu vois sur petite UT 1mn (marche d’escalier) c’est la dernière valeur connue de cette mm8 faite sur les 8 dernières “close” connues de bougies complètes grande UT 1h et ça ne bougera pas tant qu’on n’aura pas une nouvelle close de bougie 1h entière, autrement dit tu ce n’est par exemple qu’à la fin de la bougie 1mn commençant à 17h59 que tu passeras de la mm8 1h telle qu’elle était en 1h à 17h à telle qu’elle devient à 18h (17h et 18 étant ici des horaires de fin de bougie 1h, pas des horaires d’open de bougie sur l’axe du graphe, pour éviter toute ambiguité)

    – sans “updateonclose” (donc le “default”), tu as là un calcul plus dynamique de la mm8 1h basé sur [ les 7 dernières closes connues de bougies complètes grande UT 1h ] + [ en guise de 8ème valeur le dernier cours connu de la bougie 1h “en cours”, soit en graphe petite ut 1mn une série de 60 estimations successives de cette 8ème valeur qui donnent 60 calculs de mm8 UT1h ] , ça dit à chaque minute “si la bougie 1h en cours devait clôturer là, alors la mm8 du 1h serait égale à ça”, la 60ème fois étant la bonne (et étant commune avec le changement de “marche d’escalier” du updateonclose).

    #176012
    yj

    Bonjour Bywan,

    je suis tout à fait d’accord, à 200%, avec ta formulation.

    J’aurais dû être un peu plus démonstratif dans mon baratin…

    Dans les deux cas de figure la valeur des graphes est la moyenne de 8 bougies.

    Dans un cas, le cas “update on close”, les bougies sont “pleines”  ce sont des bougies d’une heure complète… C’est simple c’est clair.

    Dans l’autre cas nous avons 7 bougies pleines et une huitième qui se remplit minute après minute, pour finir pleine à la marche. C’est pour cela que les graphes se touchent.

    Ce que je trouvais amusant c’est le fait qu’à la transition on passe d’une bougie de 60 minutes à une bougie d’une minute.  Cette bougie d’une minute remplaçant la bougie pleine d’il y a 7 heures   ce qui crée une marche due non pas à la nouvelle bougie d’une minute pendant laquelle le cours a peu varié, mais à la  bougie d’une heure pleine que l’on a quittée pour cette nouvelle bougie naissante, bougie pleine pendant laquelle le cours a plus de chance de varier. (la marche étant cette variation / 8 en mm8)

    Donc la marche que l’on voit sur le graphe “not update on close” pendant la minute N°1, reflète ce qui c’est passé pendant l’heure située dans le temps, 7-8 heures avant l’instant de la marche . (Il se peut qu’il n’y ait pas de marche si le cours n’avait pas varié pendant la bougie abandonnée, open = close)

    Ensuite pendant les minutes 2 à 60 les fluctuations sont exactement celles du cours, représentées à un facteur 8 près (pour une mm8).

    Je trouvais “amusant” que le bruit soit pendant une minute ce qui se passe 8h avant et ensuite ce qui se passe maintenant, histoire de formuler cela de la manière la plus “provoquante” ou humoristique… Drôle de mélange temporel…

    Non?  yj.

    #176027

    Oui je vois ce que tu veux dire maintenant et je suis plutôt d’accord, étant adeptes de formules “glissantes” pour simuler du MTF… En même temps, la formule “default” utilisée restant en cohérence avec l’affichage du 1h dans un graphe probuilder de la mm8 variant ainsi sur bougie 1h en cours jusqu’à sa clôture, ça ne me choque pas que PRT choisisse de faire comme ça, bien que je préfère aussi autrement.

    #187552

    Bonsoir,

    j’ai l’impression qu’on ne peut pas mettre des TIMEFRAME dans des conditions.

    Quelqu’un a une idée ?

    Merci.

    #187556

    Essayez de remplacer en ligne 582 “elsif” par “if”.

    #187571

    C’est pareil avec un “If”, on ne le voit pas car il est plus haut dans le code ….

    Je vais demander à ProRealTime.

    #187573
    yj

    Avez-vous  essayé de contourner le pb en “pré-calculant”  toutes les variables dépendant des timeframe en dehors des tests if.. elseif..endif.   Si le problème persiste alors il serait ailleurs?…  yj

    #187738

    L’instruction TIMEFRAME ne peut pas être condition et donc incluse dans un bloc IF/ENDIF.

Viewing 10 posts - 31 through 40 (of 40 total)

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