Demande de boucle pour pyramidage, trailing stop et breakeven

Forums › ProRealTime forum Français › Support ProOrder › Demande de boucle pour pyramidage, trailing stop et breakeven

Viewing 15 posts - 1 through 15 (of 29 total)
1 2
  • 01/17/2019 at 8:32 AM #88887
    FREDNC

    Bonjours à tous.

    Après des heures recherche sur le site, de debugging et des dizaines d’essais infructueux, je passe la main….Si quelqu’un pouvait me coder ça, ce serait un grand merci.  Il fort probable qu’il fasse tout reprendre à zéro pour obtenir un résultat correspondant à l’idée de départ mais je ne vois pas comment faire….

    Je souhaite mettre en place un renforcement de position si le premier achat est arrivé à son niveau Trailing stop avec son Breakeven et le deuxième achat doit aussi avoir son Trailing stop avec son Breakeven

    Le calcule du SL est basé sur Close-Donchian et Niveau de start du Trailing stop c’est  abs(SL /2 ).

    Le trailing stop est sur une base d’un de code @Nicolas que j’ai essayé d’adapter sans succès.

    Soit je double mes positions, soit quand les conditions du renforcement deviennent valides, je coupe ma premier position au niveau d’entrée.

    Voici le code qui me semble se rapprocher le plus du but. J’ai supprimé tous mes filtres pour simplifier la compréhension se qui explique le nombre de positions et les résultats très médiocre. Dans tous les cas les, la condition de Breakeven de la première position n’est pas respecté pour Pyramidé. La limite de 2 positions non plus. En rajoutant les conditions « onmarket » ou « not onmarket » on crée des conflits, J’ai même eu des résultats que je n’explique même pas….lol  Bref, Je tourne en rond. Je pense qu’il faut une boucle, mais je ne sais pas faire HELP !

     

     

    01/17/2019 at 5:22 PM #88977
    Nicolas

    On ne peut pas placer 2 principes de trailing stop différents par ce biais, impossible de différencier les ordres.

    01/17/2019 at 11:15 PM #89003
    FREDNC

    Merci, pour ta réponse Nicolas. Effectivement, à partir du moment ou une deuxième position est prise Il faut raisonner et terme de prix moyen pondéré. Je vais donc opter pour un seul trailing  stop basé sur le PRU.  Les heures de debugging ont fini pat altérer mon résonnement, no comment 😉  …..

    Pourrais tu  me trouver tu une solution pour gérer le renforcement (ou pyramidage) et quel type de trailing stop serait le plus adapté ?  l’idée c’est : Si, Breakaven  du prix moyen pondéré des positions en cours (que se soit une ou X positions) donne la possibilité d’ouvrir une position supplémentaire . Par avance merci.

     

     

    01/18/2019 at 5:32 AM #89013
    FREDNC

    Voilà ci-dessous ce que j’utilise actuellement. Le Trailing c’est le tien, le système de pyramidage, je l’ai écrit avec les posts que j’ai trouvé sur le sujet.

    Peut-on améliorer ce concept ?

    Comment le trailing va t-il se comporter sur les entrée suivantes compte tenue qu’actuellement c’est (TP/2) de la première position qui active le trail ?

    A chaque nouvelles positions, nouveau TP et donc la variable “startBreakeven1” de la précédente devrait être recalculé et on perd le BE précédemment acquis … En cas de retournement et si la dernière position n’a pas pu activé son breakeven on peut redescendre au SL de la première position…

     

    01/18/2019 at 9:46 AM #89018
    Nicolas
    FREDNC wrote:

    A chaque nouvelles positions, nouveau TP et donc la variable “startBreakeven1” de la précédente devrait être recalculé et on perd le BE précédemment acquis … En cas de retournement et si la dernière position n’a pas pu activé son breakeven on peut redescendre au SL de la première position…

    Ton raisonnement est correct. Peu importe où tu placeras ton SELL ou ton EXITSHORT, l’ensemble des positions sera liquidé. Je te conseillerai d’utiliser POSITIONPRICE qui est le prix moyen de tous les ordres ouverts au marché. Par exemple, dans le cas d’une série d’ordres LONG, si tu places le stop au dessus de POSITIONPRICE, tu seras en gain global sur ton panier même si certains ordres seront perdants.

    1 user thanked author for this post.
    avatar FREDNC
    01/19/2019 at 8:57 AM #89093
    FREDNC

    Bonjour Nicolas,

    J’ai donc fait les modifications au niveau du code du “traling stop” en remplacent traderprice par  POSITIONPRICE.  Ça fonctionne bien, j’ai graphé les variables tous est OK.  Comme prévue, la deuxième position est autorisé uniquement pendant la durée du BE de la première position et si moins de x positions en cours.

    Ça ne lui laisser pas assez de temps, donc j’ai du j’ai dût redescendre mon niveau d’entré du BE et gardé le strict minimum afin que le signal de la deuxième position arrive à se caler pendant l’espace temps du BE de la première.

    Ca pourrait être rentable dans l’état, mais dans les faits on se retrouve à trailer le panier avec les paramètres de la première position et ce n’est pas rentable…

    J’ai donc imaginer une astuce. A l’aide d’un deuxième Trailling  “stop 3 bars trailing stop Williams” qui trail le “point to keept” .  A l’aide de quelque ligne de code, on indique a ton trailling stop quelle “point to keep” à utiliser en fonction du nombre de position encours.   Le résultat et très satisfaisant. (Au passage, merci à l’auteur du “stop 3 bars trailing stop Williams”)

    Voici l’astuce pour “point to keep”

    If abs(COUNTOFPOSITION)<2 then
    PtK=TP/4
    elsif abs(COUNTOFPOSITION)>1 then
    PtK=ref//variable de “stop 3 bars trailing stop Williams”
    Endif

     

    Et pour mémo voici le :  “3 bars trailing stop Williams”

    count=1
    i=0
    j=i+1
    tot=0
    while count<3 do// optimisable de temps en temps entre 2 et 10 pas de 1 ,
    tot=tot+1
    if (low[j]>=low[i]) and (high[j]<=high[i]) then
    //inside bar
    j=j+1
    else
    count=count+1
    i=i+1
    J=i+1
    endif
    wend
    basso=lowest[tot](low)
    alto=highest[tot](high)

    if close>alto[1] then
    ref=basso
    endif
    if close<basso[1] then
    ref=alto
    endif

     

     

    01/19/2019 at 9:37 AM #89096
    FREDNC

    Un commentaire, des suggestions ?

    Il y a certainement moyen d’améliorer…

    01/20/2019 at 5:03 PM #89170
    FREDNC

    Bon finalement après quelques heures de debugging et le rajout du PPJ et  2 filtres perso, la stratégie est rentable. J’ai résolu de nombreux bogs.  Le principe du renforcement si BE est validé. La sortie se fait bien sur niveau BE de la première position.  En général, le gain de la multiplication des positions est intéressant. Seul la dernière position de la série est parfois faiblement en perte et toutes les autre sont positives.

    Pour autant il me reste 2 bogs que je n’explique pas…

    -1er bog: Impossible de “grapher” le Bot1. J’ai tester, il fait bien des positions. Si conditions= buy et bot1=3 ne donne rien en “graph”.

    En revanche, pour le “Bot2”, Si conditions= buy et bot2=5 tout fonctionne , il est bien “grapher”…..bizarre.

    -2eme bog : Le BE de la première position initialise la variable “Pyra” pour autoriser le renforcement ou pyramidage. Ca fonctionne dans 90% des cas mais de temps en temps au sort sur le SL (de la première positions) et ce avec l’ensemble des positions, (ça fait mal voir le: 22 aout). Ce comportement ne devrait pas se produire car si “Pyra=1” ça veut dire que la première position est déjà à BE donc on doit sortir au BE avec ou sans renforcement. Je ne comprends pas….


    @nicolas     et les autres pouvez-vous tester et me faire part de vos suggestions ?

    Je n’ai pas réussi à importer le ITF donc voici le code final à appliquer sur  Dax (1euro), M1 , 100 000 bouigie , spread 1

     

     

     

     

     

    01/21/2019 at 8:03 AM #89196
    FREDNC

    Voilà la dernière, l’autre était vraiment boguer , Pour autant de positions de sont pas parfaites. @Nicolas ou quelqu’un d’autre pourrais y jeter un œil et m’arranger ça. Par avance merci. voici le code:

     

    01/21/2019 at 11:21 AM #89225
    Nicolas

    Désolé, mais qu’est ce qui n’est “pas parfait” et que faut-il “arranger” ? Difficile pour moi de m’investir  complètement  dans les projets de chacun sur le forum, donc il faut être très explicite pour me mettre sur la voie. Merci.

    01/22/2019 at 8:03 AM #89303
    FREDNC

    Bonjour @Nicolas,

    Effectivement j’aurais dût être plus précis.

    Ci dessous tu trouveras le new updabe du code à cette heure, j’ai encore des soucis et je t’ai fais un screen shot pour plus de compréhension .

    C’est un cycle. On commence par faire un achat avec avec le bote1.  Si breakeven+”Point to keep”+ conditions du bot2 on achète.  Puis si breakeven+”Point to keep” du panier + conditions du bot2 on achète encore et ainsi de suite

    La fin cycle c’est soit: (mono position) sortie à SL ou sortie à breakeven+”Point to keep” . Ou bien, si (Multi-positions) sortie à breakeven+”Point to keep” (du panier).

     

    Dans le screen shot (14/11/2018 à 13h18):

    1)On voit la position 1 et la 2,  rien à dire jusque là… Concernant la position 3 j’ai un doute sur le fait que le panier soit à breakeven+”Point to keep”  et la 4 et carrément en négative.

    2)Dans le graph (des variables) le cycle n’est pas respecté non plus.  (Pour info j’ai numéroté sur le graph Bot1=1 , Bot2=2, Pyra=3)

    Le cycle devrait être celà: On commence toujours par le bot1 , ensuite si BE   Pyra monte et autorise une position supplémentaire puis le bot2 et quand Pyra retombe c’est la fin du cycle .

    Le seul moyen de refaire une position c’est de repartir  du début de cycle. Dans ce cas , on voit clairement que Pyra retombe à zero mais d’autre positions du bot2 sont faites alors que Bot1 est inactif. 

    Voilà, peut tu me solutionner cela, 

     

    01/22/2019 at 5:05 PM #89351
    Nicolas

    Pas été dans le détail mais il me semble qu’il y a une erreur à la ligne 151, en effet cette ligne retournera vrai dés que countofposition sera supérieure à 0:

    par conséquent le eslif après ne sera jamais testé. Je pense que tu devrais réécrire l’ensemble comme ceci:

     

     

    01/23/2019 at 3:27 AM #89385
    FREDNC

    Merci, j’ai corrigé,

    mais on est pas encore rendu ….

    Encore plein de bogs, c’est dommage car l’idée est rentable (Screen shot joint), mais c’est il y a beaucoup de pièges quand il s’agit de l’écriture du code.

    Du reste, j’aime pas l’utilisation  “COUNTOFPOSITION” qui compte le nombre de contrats et non le nombre d’entrées. Quand on change le nombre de contrats à l’achat(valeur N) , il faut revoir tout les valeurs de “COUNTOFPOSITION” dans l’intégralité du code…. Existe t-il une fonction qui compte les entrées plutôt que les contrats ?

    01/23/2019 at 10:52 AM #89410
    Nicolas
    FREDNC wrote:

    Existe t-il une fonction qui compte les entrées plutôt que les contrats ?

    tu peux facilement incrémenter une variable dés que tu rentres en position et la reset quand tu n’es plus au marché.

    01/23/2019 at 12:51 PM #89425
    FREDNC

    Bonjour et merci pour ta réponse.

    Si je comprends bien tu pense à une boucle dans lequel on comptabilise le nombre de 1 envoyé au moment de l’entrée en position des Bot 1 et Bot2 ?

    Je ne suis pas un expert en boucle donc pourrais tu me corriger stp ?

    J’ai écris cela mais quand je graph Nbr j’ai :0

     

     

     

     

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 29 total)
1 2

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
trailing stop mfe avec tp partiel et stop ajusté
problème sur trailing stop
stop trailing sur future avec proorder
swingarm atr trailing stop
3 take profit et 2 stop loss
aide à la programmation d’un stop suiveur sur action
aide écriture stop
bande bollinger stop loss
besoin de conseils pour gestion de stop par trade
boucle 10 derniers trades

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