Je souhaite intégrer un compteur d’achats et un compteur de ventes.
L’objectif étant le suivant : si le code rencontre plusieurs signaux de ventes successifs, alors il doit réaliser qu’une tendance haussière est forte (nous sommes loin d’un range tranquille !), et à partir d’un certain nombre de signaux de ventes, au lieu de déclencher des ventes, il déclenche à chaque fois des achats –> cette configuration serait très utile en ce moment avec un DAX qui monte fortement depuis de nombreuses heures.
Je souhaite avoir votre aide sur 2 problèmes sur le code suivant passé en backtest :
le code ne prend pas un signal d’achat qui doit se présenter le 22 septembre à 3 heures 15 (alors qu’il devrait le faire) au regard de la condition d’achat pour le test, (il ne prend pas non plus le signal de vente de vendredi 22 septembre à 12 heures 45 alors que la condition de vente est vérifiée)
le compteur d’achats (= compteurachat) commence ma période backtestée à la valeur 904 –> alors qu’il devrait commencer à 0 (comme c’est le cas pour le compteur de vente (= compteurvente)
le code ci-dessous est fait pour inverser une position à chaque fois qu’un signal de retournement se présente –> s’il est déjà en position, il clôture la position ouverte, puis ouvre une autre position dans le sens inverse.
Par contre, s’il rencontre un nouveau signal identique, il ne clôture pas, mais cumule un nouvelle position.
Pourriez-vous m’aider s’il vous plaît pour les 2 problèmes rencontrés ?
les données du backtest sont données sur la capture d’écran jointe. Un GRAND MERCI à vous.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
// Définition des paramètres du code
DEFPARAMCumulateOrders=True// Cumul des positions désactivé
Je n’ai pas vérifier (tester moi même), le code, mais plusieurs choses qui pourraient t’aider :
placer les instructions GRAPH à la fin du code permet de vérifier vraiment leurs valeurs à la fin de la lecture du code, pour mémoire ProBacktest lit le code de haut en bas à chaque bougie
utilise plutôt les instructions COUNTOFLONGSHARES et COUNTOFSHORTSHARES pour vérifier la quantité de contrats (dans un sens ou dans l’autre) au marché plutôt que d’incrémenter et de décrémenter toi même des variables
Pourrais-tu voir (si tu en as le temps) pourquoi il ne prend pas en compte l’ordre d’achat de 22 septembre à 3 heures 15, alors que la condition d’achat est respectée s’il te plaît ?
Comme évoqué dans mon précédent message, avec la fonction GRAPH je peux voir que la condition ACHAT n’est pas respectée à cette horaire (en timeframe 1 minute, je ne sais pas quelle est l’unité de temps que tu utilises).
en fait, sur l’image que j’ai posté à 9h32 hier soir, il est entré en vente et à l’achat uniquement aux flèches de signaux de vente et d’achat indiquées sur cette image.
il n’y a pas d’achat le 22 septembre à 3 h 15 matin alors que la condition d’achat est vérifiée. je ne sais pas pourquoi il n’entre pas en position juste après avoir cloturé la position courte déjà ouverte (il n’a pas non plus cloturé cette position courte).
La condition ACHAT n’est pas vérifiée à 3:00, mais à 3:15, l’ordre s’ouvre donc bien à la bougie suivante.
Pour mémoire: dans probacktest, le code est lu une seule fois par barre à sa clôture et les ordres sont envoyés au marché à l’open de la barre suivante.
Merci beaucoup Nicolas, j’ai suivi tes conseils et ça fonctionne très bien maintenant, notamment avec les instructions COUNTOFLONGSHARES et COUNTOFSHORTSHARES.
De plus il prend à présent les ordres d’achat à l’heure et à la date à laquelle il ne prenait pas ces ordres. J’obtient exactement les mêmes profils que toi.
Gertrade, oui, ces 6 lignes permettent d’ajouter des ordres identiques supplémentaires lorsqu’on est déjà long ou court.
To help us continually offer you the best experience on ProRealCode, we use cookies. By clicking on "Continue" you are agreeing to our use of them. You can also check our "privacy policy" page for more information.Continue
.
