je voudrais savoir s’il est possible e faire déclencher le stoploss en cours de bougie car pour l’instant je constate que la condition du STP est bien exécutée mais à l’ouverture de la suivante. Celà conduit à plusieurs inconvénients : le niveau de sécurité est dépassé (en cas de grosse variation de cours) avant de couper la position, et je trouve des ordres contradictoires comme ouverture d’une position car les conditions sont réunies et ordre de fermeture en même temps par le stoploss de la bougie précédente .
Je n’arrive pas à résoudre ce pb … Peut-on éviter çà ?
merci d’avoir pris un peu de temps pour me répondre. J’ai posé la question parce que sur un backtest en tick par tick j’obtiens avec mon essais de stratégie sur un actif assez volatile (XAUD) un grand nombre de prise de positions (stratégie à l’achat) immédiatement coupées par le stop loss (si j’en crois les petits pointeurs qui apparaissent sur le graphique en bas de chaque côté de la bougie au même niveau). Et sur une chute de cours importante (grande bougie rouge !) le seuil du stop loss est largement dépassé et la position me semble perdante beaucoup plus que prévu d’après la courbe des gains du backtest. Comment faire pour le vérifier ? faut-il faire un test sur un time plus petit ?
Afficher à chaque bougie sur le graph les valeurs du stoploss me permettrait peut-être d’y voir plus clair , mais je ne sais pas comment faire.
Je peux trouver le fonctionnement des ordres conditionnels STP et limit dans la doc Proorder ?
Je pense que ce que tu constates sur le graphique a une explication liée à ton programme. Je pourrai t’aider beaucoup mieux et rapidement si tu partager le code ici.
Les ordres STOP et LIMIT, tu trouveras beaucoup d’exemples dans le forum, mais tu peux aussi utiliser notre documentation en ligne.
ok je vais t’envoyer le code dès que j’aurai analysé le graphe plus finement, car ce matin en résultat de backtest je n’ai presque plus le cas évoqué. En fait j’ai augmenté la valeur du stoploss, du coup la coupure intervient plus souvent sur la ou les bougies suivantes. En grossissant le graph je me suis rendu compte que le pointeur du STPL était positionné en cours de bougie ce qui me laisse penser que la coupure est bien intervenue avant la clôture.
Mais j’ai d’autres interrogations sur le fonctionnement de certaines commandes, je prépare çà et je t’envoie tout.
Ayant eu la réponse à ma question (dilater l’échelle pour voir le marqueur du STP en cours de bougie ) je reviens avec une question récurrente pour moi, je ne comprends pas comment réagit le backtest par rapport à des conditions entrées dans un petit programme de test basique: déclencher un ordre stop d’achat quand le RSI croise à la baisse 70, ou si RSI <70 quand il croise à la baisse 50.
J’ai repris le code sous forme d’un indicateur avec le scan du graph obtenu que je joins.
1
2
3
4
5
6
7
8
9
10
11
StopSA=0
ifstochastic[14,3](open)>70then
ifStochastic[14,3](open)CROSSES UNDER70then
StopSA=1
endif
else
ifStochastic[14,3](open)CROSSES UNDER50then
StopSA=1
endif
endif
returnStopSAas"STPSA"
On constate des décalages et surtout des signaux qui ne correspondent pas aux conditions : je ne comprends pas . Si tu peux m’éclaicir les idées là dessus…
Les lignes 2 et 3 ne sont pas corrects, le stochastic ne peut être à la fois supérieure à 70 (ligne 2) et avoir croisé à la baisse ce même niveau (ligne 3) 🙂
après qq jours d’activité je peux reprendre l’étude de mon petit indicateur. J’ai modifié le prgm comme tu me l’avais indiqué, et je refais le test : j’observe toujours des décalages importants et des signaux générés qui, pour moi à 1ère vue, ne correspondent pas aux conditions du programme. En fait en analysant plus finement je me rends compte qu’il apparaît:
– un décalage (1 ou 2 bougies de plus) si le franchissement graphique (cas 1)se fait entre 2 bougies (dans le time choisi : ici 1H). Il faudrait donc descendre à un time plus faible pour avoir une meilleure synchro et obtenir le signal stop plus rapidement ?
– de même ce retard peut arriver complètement en contre sens de la tendance, ce qui est gênant ! (cas 2)
Je remarque plusieurs choses pas trop cohérentes, à la fois dans le code et dans l’image que tu as posté 🙂
tu souhaites constater un croisement d’une stochastique avec des niveaux, hors pour le constater, on attend que la bougie ait clôturé et donc en effet, il y a un “décalage” d’1 bougie.
tu calcule la stochastique avec l’Open, pas de problème pour moi mais à 99% on utilise toujours le Close pour calculer un indicateur: Stochastic[14,3](close), cela pouvant impliquer cet effet de décalage visuel que tu constates.
dans ton image, tu affiches un stochastique RSI, qui n’est pas du tout le même indicateur que celui de ton code ..
quand tu affiches un indicateur sur le graphique pour vérifier le code, pense à bien utiliser les mêmes périodes et setting (calculé sur l’open ou le close, etc.).
un indicateur étant calculé sur une période X avec des données OHLC des bougies du timeframe observé, réduire l’unité de temps pour ‘aller plus vite’ ne fera que brouiller l’intention. En effet, une situation de survente en H1, ne l’ai pas en M5. Ne pas oublier qu’une stochastique, c’est juste la variation en pourcentage du prix entre 2 bornes.
j’ai regardé les différents points pour améliorer l’algorithme. C’est pas encore terrible mais çà progresse, je comprends un peu mieux l’exécution du pgm.
Par contre je reste encore bloqué sur mon problème de déclenchement de StopLoss.
Je t’envoie un petit document word de présentation du cas.
Merci de poster le message dans le forum la prochaine fois, les documents séparés ne participent pas à la fluidité des échanges et pour les futures références.
Avec un SET STOP LOSS, le stop loss est bien envoyé au courtier pour l’inscrire dans son carnet d’ordres, donc il sera exécuté au prix demandé et d’autant plus si il s’agit d’un stop garanti.
Dans ProBacktest, une croix sur le graphique signifie “exit”, soit une sortie de position demandée par le code. Je n’ai pas tout le code, difficile de te répondre.
.
