Retard de 2 périodes entre le déclencheur et l’ordre

Forums › ProRealTime forum Français › Support ProOrder › Retard de 2 périodes entre le déclencheur et l’ordre

Viewing 11 posts - 1 through 11 (of 11 total)
  • 01/28/2024 at 5:22 PM #226977
    davidguerreir

    Bonjour,

    J’ai un gros problème lors de mes backtests,

    En effet, quelles que soient les indicateurs utilisés, il y a systématiquement un décalage de 1 à 2 temps entre un déclencheur et un ordre automatique

    Questions :
    _Comment peut-on résoudre ce problème de décalage temporel entre un déclencheur et une action d’achat/vente?
    _Est-il dû seulement au backtest et donc inexistant dans le trading temps réel?

    Exemple de backtest utilisé : On utilise PRT court terme (fréquence 1h) qui en temps réel (si l’ordre était passé dans l’heure) serait un indicateur parfait pour isoler les mouvements en hausse en évitant les baisses
    La fonction est simple : si PRT passe sous le cours, on achète X actions, et si il en sort on vend X actions.

    Le problème : Lorsque les courbes se croisent en T, l’ordre n’est passé que en T+1 ou T+2, sur une fréquence d’analyse de 1H se traduit par 2 heures de décalage, de telle sorte que les indices les plus proches des variations sont totalement inutilisables.

    C’est pour cela que l’indice SMA[20] simple est encore un des indices donnant les meilleurs résultats en BACKTEST, contre toute logique, car se focalisant sur des variations plus grandes, il sera moins en échec face au décalage important entre le déclencheur et l’ordre.

    Formule utilisée :

    PRT = PRTBandsShortTerm

    IF NOT ONMARKET THEN
    IF CLOSE CROSSES OVER PRT THEN
    BUY 10 SHARE AT MARKET
    ENDIF
    ENDIF

    IF ONMARKET THEN
    IF CLOSE CROSSES UNDER PRT THEN
    SELL 10 SHARE  AT MARKET
    ENDIF
    ENDIF

    GRAPHONPRICE PRT

    Merci par avance pour votre aide la trade communauté 

    01/28/2024 at 8:06 PM #226981
    Nicolas

    Ce que tu observes est en fait un décalage visuel.

    Ce décalage est dû au fait que les symboles et les indications sur les graphiques s’affichent généralement à l’ouverture de la bougie suivante. Donc, même si cela peut sembler comme un retard, en réalité, c’est juste une question de représentation graphique.

    Pour ton cas spécifique, le croisement des valeurs est évalué à la fermeture du chandelier. Si la condition de croisement est remplie à la clôture, l’ordre est alors envoyé à l’ouverture de la bougie suivante. C’est pourquoi tu as l’impression qu’il y a un décalage de temps, alors qu’en réalité, c’est simplement la manière dont les informations sont présentées sur le graphique.

    En résumé, ce que tu perçois comme un décalage dans l’exécution des ordres est en fait un alignement correct avec la logique de trading basée sur les données de clôture des chandeliers. L’ordre est exécuté au bon moment, mais il est affiché visuellement avec un léger décalage sur le graphique.

    01/28/2024 at 8:29 PM #226985
    davidguerreir

    Merci beaucoup pour ta réponse Nicolas,

    Cela étant, si c’est bien le cas, et qu’il s’agit uniquement d’un retard visuel,  je n’arrive pas à expliquer que la stratégie basée sur un PRT court terme -à l’achat quand il passe sous le cours, et à la vente lorsqu’il est supérieur au cours- ne soit pas rentable, tandis que le déclencheur isole parfaitement les segments de courbe à la hausse tout en évitant la grande majorité des segments à la baisse.

    Selon toute vraisemblance si les actions sont bien effectuées en temps réel, pour un cours à la hausse et avec l’indicateur PRT court terme sur une fréquence d’1H, je devrais obtenir une performance (hors frais de trade) positive et supérieure au simple fait de posséder passivement les actions. (Selon l’observation graphique)

    Cela dit les Backtests ne donnent pas du tout ce résultat, ils donnent un résultat neutre, sans aucun gain, même dans un cours à la hausse. comment expliquer cela ?

    01/29/2024 at 10:50 AM #226995
    Nicolas

    Avec ton code j’obtiens beaucoup d’ordres sur Hermes en daily, voir image jointe.

    1 user thanked author for this post.
    avatar davidguerreir
    01/29/2024 at 2:05 PM #227012
    davidguerreir

    Bonjour Nicolas,

    Voici un autre exemple, toujours avec Hermes fréquence 1 Jour cette fois, ici nous voyons clairement l’effet du décalage sur le résultat de l’achat (au croisement à 1843/u) puis de la vente de 10 actions (au croisement à 1878/u)

    Si l’opération était réellement instantanée, alors l’achat aurait du survenir rigoureusement au croisement (PRT<close) pour 18430 € au total, puis revendu au croisement suivant (PRT>close) pour 18780, un bénéfice net de courtage de 332€ aurait dû résulté, tandis qu’ici nous avons bien une perte de 450 € (soit clairement la tendance entre les deux points d’achat et vente affichés, étant décalés de 1 à 2 jours des points de déclenchement programmés par croisement de courbes, voir screen joint)

    Il en résulte que dans mon Backtest il y a bien un décalage entre mon déclencheur (l’exécution de ma formule) et le passage réel d’ordre au marché.

    Ma grande inquiétude est de savoir si ce décalage persisterait si je devais aller sur le marché réel au lieu de l’environnement de Backtest.

    01/29/2024 at 3:53 PM #227022
    Nicolas

    Reprenons 🙂

    Dans cette image on constate un croisement à l’instant T (voir ma flèche rouge): le 13 au soir, la courbe est dessous, le 14 au soir la courbe est au dessus: on a bien un croisement. On envoi l’ordre qui s’ouvre à l’open suivant, soit la flèche que tu vois le 15.

    Si tu veux ouvrir un ordre durant la journée, il faudra adapter ta stratégie. Cependant ce que tu vois sur ton graphique historique ce sont des données à la clôture, hors il est fort probable que le croisement a eu lieu X fois, donc tu peux partir à l’achat par exemple et en fin de journée la courbe est finalement restée en dessous.

    1 user thanked author for this post.
    avatar davidguerreir
    01/29/2024 at 6:30 PM #227033
    davidguerreir

    Bonsoir Nicolas,

    En effet je perçois enfin la logique, c’est beaucoup plus clair : si l’échelle de temps est 1 jour la fonction ne pourra lire les données qu’une fois par jour correspondant aux données de clôture/ouverture de chaque jour, cela dit, est-il possible d’envisager que le bot se base sur des valeurs “temps réel” au lieu des valeurs de clôtures ou d’ouvertures ?

    Donc je dois demander à ma fonction d’aller chercher les données open/close à un niveau périodique “Heure” ou “Minutes” pour obtenir les données “temps réel” qui pourraient me permettre de déclencher plus tôt mes ordres tout en suivant la tendance et mes indices au niveau “Day” pour fixer les seuils déclencheurs

    Dans ce cas le principe serait de lire dans un premier temps mes données à l’échelle “minute”/”hour” puis dans un second temps d’aller vers le plus grand et tracer ma courbe de tendance “day” puis ajouter le cours à l’échelle “day”

    Je peux donc réctifier mon déclencheur :

    open1 = open (timeframe 1 heure)
    open2 = open (timeframe 1 day)
    IF open1 </> SMA OR open2 </> SMA THEN
    BUY/SELL 10 share AT MARKET

    Ne pouvant appeler que des unités de temps qui sont des multiples plus grand que le graphique de base, je dois partir de la période la plus petite (ici 1h) et appeler la plus grande (1 jour)

    Voici donc le nouveau code qui ajoute la notion de réactivité dans ma formule de base :

    TIMEFRAME(daily)
    open1 = open

    timeframe(1hour)
    SMA=Average[Periods](close)
    open2 = open

    IF NOT ONMARKET THEN
    IF open1 > SMA OR open2 > SMA THEN
    BUY 10 share AT MARKET
    ENDIF
    ENDIF

    if onmarket THEN
    if open1 < SMA OR open2 < SMA THEN
    sell 10 share at market
    ENDIF
    ENDIF

    GRAPHONPRICE SMA
    GRAPHONPRICE open1

    Merci infiniment, les résultats obtenus sont déjà bien meilleurs et je suis rassuré sur le fait qu’il est tout à fait possible d’être réactif par rapport au “court actuel” ! 🙂

    Cela étant il s’est passé certaines actions assez étranges dans mon tests : sans aucune raison un déclencheur de vente s’est activé tandis que la courbe trend n’a jamais dépassé mes courbes d’ouvertures.

    01/30/2024 at 9:22 AM #227066
    Nicolas

    Une de ces conditions a forcément était vrai: open1 < SMA OR open2 < SMA

    A vérifier avec les chandeliers affichés sur ton graphique 🙂

    1 user thanked author for this post.
    avatar davidguerreir
    01/30/2024 at 8:07 PM #227119
    davidguerreir

    Merci Nicolas,

    Effectivement sur ma dernière formulation j’ai changé les “crosses over/under” de la fonction de base par des < / >,  donc forcément les ordres deviennent facilement contradictoires par moments

    En repassant en “cross” le résultat est encore bien meilleur, je retiens que l’analyse sur un double temps est capable d’améliorer une fonction,

    J’ai d’ailleurs codé une fonction “TIME TRAVEL TREND” purement temporelle qui prend une décision selon la tendance entre la fermeture du cours et son ouverture ainsi que les variations du cours heure / cours jour et cela donne de superbes résultats (2X supérieur, net, au rendement passif sur une courbe à la hausse) :

     

     

    Cela dit la stratégie n’est pas meilleure pour l’instant que la stratégie gagnante basique donnée par le logiciel “Exemple d’optimisation” : Sa grande force est d’utiliser des variables d’après ce que j’ai compris, l’IA est capable des les optimisés dans un contexte. Ainsi sur des variables comme des %LOSS ou %PROFIT ce sera mieux gérer en variables qu’en utilisant une fonction %TRAILING et en fixant un montant

    →”Exemple d’optimisation” (SMA CROSS IN + STOP LIMIT)

     

    J’aimerais mieux comprendre comment les variables sont exploitées par l’IA
    Car quand je définis un stop %loss de 1, cela n’a rien à voir avec un stop %loss de “a” avec a = variable valant initialement 1

    Tout ce que nous utilisons comme variable va être analysé par l’ordinateur sur des scénarios passés et futurs pour essayer de prédire quel est la meilleure façon de l’adapter à l’environnement immédiat et à la tendance actuelle ?
    Si en simulation cela donne de superbes résultats, n’est-ce pas un facteur de risque dans une situation réelle si le PC s’emballe dans ses calculs de variables ?

    Quelqu’un aurait une expérience des variables pour savoir si elles sont fiables ?

    01/31/2024 at 9:46 AM #227144
    Nicolas

    Félicitations pour tes codes qui fonctionnent désormais.

    Je vois que tu commences à faire de l’optimisation, tes questions sont légitimes et font appel à des notions plus vastes mais très importante sur ce sujet …

    Il est important de rester vigilant face aux pièges potentiels tels que la sur-optimisation et l’ajustement excessif de la courbe de rendement (equity curve overfitting).

    La sur-optimisation se produit lorsque ta stratégie est trop bien ajustée aux données historiques, au point de perdre sa capacité à performer sur de nouvelles données non testées. Cela peut mener à des prévisions irréalistes et décevantes en trading réel.

    L’ajustement excessif de la courbe de rendement, ou “equity curve overfitting”, survient lorsque les paramètres de la stratégie sont modifiés de manière à créer une courbe de rendement apparemment parfaite sur le passé, mais qui ne se répète pas dans le futur.

    Pour “éviter” ces écueils, la plateforme propose le module de “Walk Forward Analysis” (WFA). Ce module permet de tester la robustesse d’une stratégie en l’appliquant à des données inédites après l’optimisation, en simulant ainsi sa performance dans des conditions de marché changeantes. L’approche Walk Forward aide à valider la stabilité et la fiabilité d’une stratégie sur le long terme.

    Je te recommande vivement de consulter les sujets existants sur le forum de ProRealCode pour approfondir ta compréhension de l’optimisation et du Walk Forward Analysis. Tu y trouvera des discussions, des conseils et des exemples pratiques partagés par la communauté. Voici quelques sujets à explorer :

    “Introduction au Walk Forward Analysis sur ProRealTime”

    Analyse Walk Forward avec ProRealTime

    Récapitulatif sur l’utilisation du module Walk Forward sous ProRealTime

    https://www.prorealcode.com/blog/learning/prorealtime-walk-analysis-tool/

    https://www.prorealcode.com/topic/walk-forward-analysis/

    etc…
    Ces discussions peuvent vous fournir des insights précieux et des retours d’expérience pour améliorer votre approche de l’optimisation des stratégies de trading.

    N’oubliez pas, une stratégie bien testée et robuste est clé pour réussir dans le trading. Bonne chance dans votre recherche et développement !

    1 user thanked author for this post.
    avatar davidguerreir
    02/19/2024 at 3:14 PM #228399
    Skale

    Bonjour,

    Je me permets d’intervenir dans la discussion car j’ai également un problème de temps à résoudre.

    Dans mon code ma sortie est faite « à l’ouverture de la barre suivante » dès lors que mon signal est arrivé. Or, je souhaiterais sortir à l’instant où mon signal intervient pour éviter que ça me cause un léger décalage qui ne me correspond pas.

    Connaissez-vous une solution pour ça ? Une partie de code à rajouter peut-être ?

    Merci par avance pour votre aide 🙂

  • Author
    Posts
Viewing 11 posts - 1 through 11 (of 11 total)

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
améliorez la gestion de l’espacement entre les bougies svp!
drawrectangle entre plus haut et plus bas de l’overnight
entrer en position avec l’ichimoku – 26 périodes en arrière
identification de l’écart le plus petit sur les 50 dernières périodes
passage d’un ordre à l’ouverture d’une bougie

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