indicateur ziz-zag et MACD

Forums ProRealTime forum Français Support ProBuilder indicateur ziz-zag et MACD

Viewing 13 posts - 1 through 13 (of 13 total)
  • #243693

    Bonjour à tous, j’aimerai créer un indicateur qui me relie  sur les prix ,à la façon du “ziz-zag”, les points hauts et les points bas. Le point haut serait le prix le plus haut sur la période positive des histogrammes du MACD ( et non pas pas la valeur du cours où l’histogramme est le plus grand sur cette période) .  Le points bas serait le prix  le plus bas sur la période négative du MACD (et non pas la valeur du cours où l’histogramme est le plus grand dans cette période).  j’espère que ma formulation est assez explicite…J’ai essayer mais mes “talents” de programmateur sont plus que limite…….

    Merci par avance à tous, que se soit possible ou pas.

    Bonne journée.

    Bien cordialement.

     

    #243700

    Bonjour,

    Indicateur à ajouter dans la fenêtre du prix (niveaux sur la verticale sont les prix plus hauts plus bas pendant les phases de macd-histogramme, barre du changement de trait sur l’horizontale apporte l’info supplémentaire de marquer sur quelle barre macd-histogramme change de signe) :

     

    2 users thanked author for this post.
    #243727

    Bonjour Mr JC  BYWAN, tout d’abord un grand merci pour le retour, le temps consacré à l’écriture de ce code et l’intérêt de ma demande. Ce code correspond en grande partie à mes attentes sauf que j’aurais aimer ( mais je ne sais pas si c’est possible) que le tracer se fasse sur la bougie la plus haute lors d’un MACD positif et sur la bougie la plus basse sur un MACD négatif. Sur le code que vous m’avez gentiment créer  , cela donne une impression de décalage par rapport à ce plus haut et ce plus bas. En conclusion: la modification est elle réalisable ?.

    Merci par avance.( Que ce soit possible ou pas )

    Bonne journée.

    Bien cordialement.

    #243730

    C’est faisable, cela dit l’indicateur fera du repaint (c’est à dire un tracé à postériori).
    Le plus haut et le plus bas étant détectés qu’à postériori, ils vont être tracé au même moment mais sur 3, 4 ou 5 bougie en arrière…
    C’est flatteur lorsque l’on regarde le graphe, mais ça n’apporte rien de plus pour une utilisation concrète lors du trading.

    L’intérêt de l’indicateur tel qu’il est actuellement est de bien se rendre compte que la plupart du temps le MACD (dû au retard des moyennes mobiles, abouti à l’effet porte de saloon…

    1 user thanked author for this post.
    #243735

    Si tu préfères le visualiser ainsi, voici la modif (à tester). Au-delà du code lui-même, je rejoins LaMaille dans l’esprit de ce qu’il a voulu dire par rapport au temps réel et à l’utilité dans le trading, juste pour être pointilleux je n’aurais pas utilisé le terme “repaint” ici au sens où le terme va plus loin que juste un tracé a posteiori, c’est un tracé qui peut changer quand il prend en compte les nouvelles infos des nouvelles bougies. Or je l’ai intentionnellement codé anti-repaint, c’est à dire en traçant uniquement la partie qui ne change pas, de sorte que le dernier segment n’est tracé qu’une fois qu’il est connu de façon définitive, sans tracé provisoire variable via un drawonlastbaronly, ni lookback et boucle consommatrice de temps de calcul depuis la barre en cours. Par conséquent du point de vue coding il n’est pas modifié (repainted) selon le moment où on lance l’indic. Mais sinon effectivement ce n’est pas exploitable pour le temps réel, ça l’est pour se faire son idée sur un historique de graphe de la pertinence ou pas de ce que l’on pensait voir avec le macd, et choisir de poursuivre ses recherches en ce sens… ou passer à autre chose…

     

     

    1 user thanked author for this post.
    #243737

    Re bonjour, Merci infiniment pour ce nouveau code qui colle parfaitement à ce que je voulais. ( juste que sur certaines grandes mèches basses, le segment commence en plein milieu de la mèche : mais pas gênant plus que ça..). J’entends vos arguments sur le REPAINTED mais mon objectif est bien comme l’a mentionner Monsieur JC BYWAN de me faire une idée sur un historique de graphe de la pertinence ou pas de ce que l’on  pense voir avec le MACD.

    Encore une fois merci infiniment pour ce code et merci à vous deux pour vos commentaires sur ma demande.

    Bonne journée.

    Bien cordialement.

    #243809

    J’aurais pensais qu’il était possible de modifier le code en rajoutant seulement 2 lignes, avec l’instruction barssince, mais ça n’a pas l”air de fonctionner… Une petite idée du pourquoi? Apparemment, barssince ne fonctionne pas avec low (ou high) = une valeur…

    #243812

    Bien sûr en mettant barbottom à la place de barcrossup et … dans drawsegment.

    L’instruction Barssince semble avoir un problème, non ?

    #243878

    Bonjour Lucas,

    Votre tentative d’utiliser barssince pour identifier la barre spécifique où le plus bas ou le plus haut a été atteint est intéressante, mais il semble y avoir une confusion sur l’utilisation de cette fonction. La fonction barssince(condition) est conçue pour retourner le nombre de barres depuis qu’une condition booléenne a été vraie pour la dernière fois. Cependant, l’utilisation de low = redbottom ou high = greentop comme condition n’est pas valide car ces expressions ne retournent pas une condition booléenne mais tentent d’assigner une valeur, ce qui n’est pas le comportement attendu dans ce contexte.

    Pour corriger cela, vous devez reformuler la condition pour qu’elle retourne un booléen. Voici une approche possible en utilisant une comparaison directe dans la condition :

    Notez que j’ai utilisé redbottom[1] et greentop[1] pour accéder à la valeur précédente de redbottom et greentop, respectivement. Cela est nécessaire car barssince doit évaluer une condition sur les valeurs historiques des barres précédentes.

    J’espère que cela vous aide à clarifier l’utilisation de barssince et à ajuster votre code en conséquence!

    Bonne programmation,

    #243892

    Bonjour Lucas,

    Votre tentative d’utiliser barssince pour identifier la barre spécifique où le plus bas ou le plus haut a été atteint est intéressante, mais il semble y avoir une confusion sur l’utilisation de cette fonction. La fonction barssince(condition) est conçue pour retourner le nombre de barres depuis qu’une condition booléenne a été vraie pour la dernière fois. Cependant, l’utilisation de low = redbottom ou high = greentop comme condition n’est pas valide car ces expressions ne retournent pas une condition booléenne mais tentent d’assigner une valeur, ce qui n’est pas le comportement attendu dans ce contexte.

    Pour corriger cela, vous devez reformuler la condition pour qu’elle retourne un booléen. Voici une approche possible en utilisant une comparaison directe dans la condition :

    les expressions “low = redbottom” et “high = greentop” ne peuvent être considérées par prorealtime comme des tentatives d’assigner une valeur à Low ou High qui sont des constantes non modifiables par le code… Le code retournerait une erreur si prorealtime considérait cela comme une tentative d’assigner des valeurs à Low ou High. Il considère bien ces deux expressions comme des conditions.

    Que ce soit “low = redbottom[1]” ou “low = redbottom”, cela ne change strictement rien…
    Dans les deux cas, Barssince retourne -1 indiquant que la condition n’est jamais vrai.

    En mettant en ligne 6 : DRAWSEGMENT(bartop, greentop, barbottom, redbottom) COLOURED(“red”)
    et en ligne 12 : DRAWSEGMENT(barbottom, redbottom, bartop, greentop) COLOURED(“green”)
    on se rend compte que l’indicateur trace les segments toujours une bar après que l’histogramme passe du positif au négatif ou vive versa.
    On retrouve donc bien Barindex – (-1) = Barindex + 1

    Je pense plutôt que le code prends les valeurs que Low et que redbottom avaient lors des bougies précédantes. Ce qui est bien pour le cas de Low, mais pas désiré dans le cas de redbottom, à qui on vient d’assigner une nouvelle valeur… Il faudrait avoir la possibilité d’assigner une valeur à une constante (qui n’existent pas dans ce langage).
    Néanmoins il existe une solution… L’utilisation d’un tableau pour stocker les valeurs greentop et redbottom…

    1 user thanked author for this post.
    #243989

    Bonjour MR LucasBest, tout d’abord félicitation car la correction que vous avez apporté au programme corrige les séquences où le tracé se faisait au mauvais endroit sur la bougie.

    Visiblement il fallait se montrer astucieux.

    Ensuite et si ce n’est pas trop vous accaparez…:  Comment feriez-vous pour tracer une ligne entre 2 sommets ou 2 creux ?.

    j’ai essayer en alternant les $redbottom[0] et/ou[1 ]  ,suivi de bartop [0] et /ou [1]…mais cela ne donne rien.

    Enfin un grand et sincère merci à tous les intervenants de ce site qui prenaient de votre temps pour aider les autres.

    Bonne journée à tous.

     

    #244023

    Il suffit d’enregistrer les précédants plus haut et plus bas avant de calculer les nouveaux…

    Le code a été rectifié directement dans le message et n’a donc pas été testé…
    S’il fonctionne correctement, je vous laisse en faire de même pour les segments reliant les plus haut.

    1 user thanked author for this post.
    #244062

    Merci infiniment. Le code fonctionne parfaitement bien .De plus , les notes explicatives dans le programme sont très enrichissantes pour apprendre.

    Le code reliant les plus haut a forcement était plus facile avec tout votre  travail et vos  explications en amont.

    Merci encore.

    Bonne journée.

Viewing 13 posts - 1 through 13 (of 13 total)

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