OLGParticipant
Junior
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
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
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.
OLGParticipant
Junior
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.
OLGParticipant
Junior
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
Remplacez la ligne 9 par:
ONCE xSignalAchat = 0
Remplacez les lignes 15-16 par:
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.
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
OLGParticipant
Junior
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
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
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é
