FLATBEFORE et CROSSES OVER/UNDER

• 08/26/2020 at 6:13 PM #142637
  OLG

  Bonjour,

  Navré si cette question a déjà été posé , j’ai pourtant fait l’effort de rechercher sur le forum et dans la documentation mais je ne trouve pas la réponse.

  En codant une stratégie je me suis aperçu plusieurs fois que le système ouvre un trade à l’heure d’autorisation des trades si un signal “CROSSES” est apparu durant la plage d’interdiction des trades.

  Plus concrètement j’interdis l’ouverture des trades après 22h00 et avant 8h45 (FLATAFTER et FLATBEFORE).

  La condition d’ouverture d’un trade est que “a” CROSSES OVER “b”.

  Si “a” a croisé à la hausse “b” à 7h00 (donc pendant la période flat) et qu’il ne recroise pas à la baisse, à 8h45 le trade est ouvert.

  Est-ce normal ? J’utilise CROSSES OVER/UNDER en instantané, donc le trade doit s’ouvrir au début de la bougie suivante. Ça marche parfaitement durant la période de trade.

  Mais j’ai l’impression que le CROSSES OVER est un “flag” qui n’est “annulé” que si il est CROSSES UNDER …

  Avez vous constaté cela ? est ce un bug ? est ce normal ?

  Au poire j’utiliserai une formule du genre “a[1]<b[1] AND a>b” mais le CROSSES OVER est quand même plus facile à la lecture du code.

  D’avance merci,

  Regis

  

  OLG

  Participant

  Topics: 2

  Replies: 7

  Been thanked: 2 times
  09/24/2020 at 4:26 PM #145249
  Nicolas

  En effet CROSSES OVER/UNDER est testé sur la barre courante et ne retourne pas “true” durant plusieurs périodes.

  Par contre, si tu as enregistré sa valeur dans une autre variable et que celle-ci n’est pas remise à zéro, alors cette condition persiste, par exemple :

  if a crosses over b then test = 1 endif

  1 2 3

  if a crosses over b then test = 1 endif

  ici tant que test n’est pas remis à zéro quelque part ailleurs dans le code, alors il restera à 1 (vrai) et donc pourra agir comme une condition pour ouvrir un ordre.

  1 user thanked author for this post.

  OLG

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4775 times
  09/24/2020 at 5:23 PM #145264
  OLG

  Merci Nicolas,

  Dans mon cas, il n’y a pas d’utilisation de variable, je vais faire un programme spécifique pour mettre en exergue ce que je pense être un bug.

  Il ne s’agissait pas d’une variable stockée, mais bien du test CROSS OVER/UNDER qui était valide dés que le FLATE BEFORE se “terminait” alors que le CROSS avait eu lieu durant la période “flat” et non à la bougie courante.

  Bref … un exemple (code et graph) sera plus parlant ! Je m’y atèle dés que possible.

  

  OLG

  Participant

  Topics: 2

  Replies: 7

  Been thanked: 2 times
  09/24/2020 at 9:13 PM #145280
  OLG

  Bon je n’arrive pas à reproduire le cas de figure, et je n’ai pas conservé le code de l’époque … donc soit je n’avais vraiment pas les yeux en face des trous (fortement probable) soit c’est un bug qui ne se produit que dans certaines conditions (peu probable)

  Voici le code utilisé pour tenter de le reproduire, on sait jamais si je retombe dessus je pourrais faire des tests :

  DEFPARAM CumulateOrders = False DEFPARAM PRELOADBARS = 3000 DEFPARAM FLATBEFORE = 084500 DEFPARAM FLATAFTER = 220000 noEntryBeforeTime = 084500 noEntryAfterTime = 220000 daysForbiddenEntry = OpenDayOfWeek = 6 OR OpenDayOfWeek = 0 AuthorizedEntries = (time >= noEntryBeforeTime) AND (time < noEntryAfterTime) AND NOT (daysForbiddenEntry) iPetiteMM = Average[20](close) iGrandeMM = Average[200](close) IF AuthorizedEntries THEN cSignalAchat = iPetiteMM CROSSES OVER iGrandeMM cSignalAchat = cSignalAchat AND NOT ONMARKET IF cSignaleAchat THEN EXITSHORT AT MARKET BUY 1 CONTRACT AT MARKET SET STOP pTRAILING 20 ENDIF ENDIF

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  DEFPARAM CumulateOrders = False DEFPARAM PRELOADBARS = 3000     DEFPARAM FLATBEFORE = 084500     DEFPARAM FLATAFTER = 220000     noEntryBeforeTime = 084500       noEntryAfterTime = 220000       daysForbiddenEntry = OpenDayOfWeek = 6 OR OpenDayOfWeek = 0 AuthorizedEntries = (time >= noEntryBeforeTime) AND (time < noEntryAfterTime) AND NOT (daysForbiddenEntry)   iPetiteMM = Average[20](close) iGrandeMM = Average[200](close)   IF AuthorizedEntries THEN   cSignalAchat = iPetiteMM CROSSES OVER iGrandeMM cSignalAchat = cSignalAchat AND NOT ONMARKET   IF cSignaleAchat  THEN EXITSHORT AT MARKET BUY 1 CONTRACT AT MARKET SET STOP pTRAILING 20 ENDIF   ENDIF

   

  

  OLG

  Participant

  Topics: 2

  Replies: 7

  Been thanked: 2 times
  09/24/2020 at 9:45 PM #145282
  robertogozzi

  Remplacez la ligne 9 par:

  ONCE xSignalAchat = 0

  1	ONCE xSignalAchat = 0

  Remplacez les lignes 15-16 par:

  IF iPetiteMM CROSSES OVER iGrandeMM THEN xSignalAchat = 1 ENDIF cSignalAchat = xSignalAchat AND Not OnMarket

  1 2 3 4

  IF iPetiteMM CROSSES OVER iGrandeMM THEN    xSignalAchat = 1 ENDIF cSignalAchat = xSignalAchat AND Not OnMarket

  Cela devrait se comporter comme vous l’avez dit. xSignalAchat conserve sa valeur après le croisement, jusqu’à ce que vous le remettiez à zéro.

  

  robertogozzi

  Moderator

  Topics: 69

  Replies: 17298

  Been thanked: 4135 times
  09/25/2020 at 7:50 AM #145298
  Nicolas

  Le problème c’est que tu ne reset pas ta variable cSignalAchat lorsque tu es hors AuthorizedEntries, on le voit bien dans l’image que j’ai jointe à ce message.

  Ta condition booléenne est testé uniquement si tes conditions horaires sont valables, hors si à la barre juste avant tu as testé vrai, et que tu ne peux plus la tester dés la barre d’après, cette condition restera active (puisque elle ne ne sera plus testé) et donc ça impactera ton backtest.

  Pour tester des variables, il faut utiliser l’instruction GRAPH.

  graph AuthorizedEntries coloured(255,200,0) graph cSignalAchat

  1 2	graph AuthorizedEntries coloured(255,200,0) graph cSignalAchat

   

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20863

  Been thanked: 4775 times
  11/05/2020 at 10:56 AM #149516
  OLG

  Bonjour à tous,

  Merci pour vos réponses, j’ai pris le temps de pouvoir de nouveau constaté ce problème, et j’ai réussi à le reproduire et à comprendre sa cause !
  Le problème ne vient pas du CROSSES UNDER/OVER mais vient du fait que dans mon algorithme original (pas celui présenté dans ce fil de discussion) le calcul des indicateurs était dans le bloc de condition comme ceci :

  DEFPARAM CumulateOrders = False DEFPARAM PRELOADBARS = 3000 DEFPARAM FLATBEFORE = 084500 DEFPARAM FLATAFTER = 220000 noEntryBeforeTime = 084500 noEntryAfterTime = 220000 daysForbiddenEntry = OpenDayOfWeek = 6 OR OpenDayOfWeek = 0 AuthorizedEntries = (time >= noEntryBeforeTime) AND (time < noEntryAfterTime) AND NOT (daysForbiddenEntry) IF AuthorizedEntries THEN iPetiteMM = Average[20](close) iGrandeMM = Average[200](close) cSignalAchat = iPetiteMM CROSSES OVER iGrandeMM cSignalAchat = cSignalAchat AND NOT ONMARKET IF cSignaleAchat THEN EXITSHORT AT MARKET BUY 1 CONTRACT AT MARKET SET STOP pTRAILING 20 ENDIF ENDIF

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  DEFPARAM CumulateOrders = False DEFPARAM PRELOADBARS = 3000     DEFPARAM FLATBEFORE = 084500     DEFPARAM FLATAFTER = 220000     noEntryBeforeTime = 084500       noEntryAfterTime = 220000       daysForbiddenEntry = OpenDayOfWeek = 6 OR OpenDayOfWeek = 0 AuthorizedEntries = (time >= noEntryBeforeTime) AND (time < noEntryAfterTime) AND NOT (daysForbiddenEntry)    IF AuthorizedEntries THEN   iPetiteMM = Average[20](close) iGrandeMM = Average[200](close)   cSignalAchat = iPetiteMM CROSSES OVER iGrandeMM cSignalAchat = cSignalAchat AND NOT ONMARKET IF cSignaleAchat  THEN EXITSHORT AT MARKET BUY 1 CONTRACT AT MARKET SET STOP pTRAILING 20 ENDIF ENDIF

  Lorsque l’indicateur n’est pas calculé (car AuthorizedEntries = 0) il prend la valeur 0, ce qui lorsqu’il est calculé de nouveau, provoquait déclenchait logiquement les CROSSES UNDER/OVER.
  Merci Nicolas, tu avais cerné le problème “à l’aveugle” et même si ce n’était pas exactement cela, c’était bien un problème de ce type.

  J’incluais le calcul de mes indicateurs dans mes blocs de conditions afin d’optimiser les temps de calcul, mais cela ne s’avère pas toujours pertinent… la preuve !

  Désolé de “déterrer” ce post, il me semblait judicieux d’apporter la réponse finale si quelqu’un fait la recherche plus tard.

  @+
  Regis

  2 users thanked author for this post.

  GraHal, JC_Bywan

  

  OLG

  Participant

  Topics: 2

  Replies: 7

  Been thanked: 2 times
  11/05/2020 at 11:01 AM #149518
  JC_Bywan

  Merci d’avoir livré ta conclusion même longtemps après, les discussions des topics étant effectivement aussi lues via le moteur de recherche du site, c’est toujours utile sur la durée pour la communauté

  1 user thanked author for this post.

  GraHal

  

  JC_Bywan

  Moderator

  Topics: 20

  Replies: 2681

  Been thanked: 949 times
• Author
  Posts