1/ avec les données du futur (ce qui n’est pas possible à récupérer pour le trading automatique)
2/ avec les données du passé (là oui on le peut mais il faudra utiliser la formule du DPO directement dans le code et non pas l’indicateur embarqué dans la plateforme).
Voici la formule du DPO :
1
2
3
4
5
6
7
8
9
10
// **** DPO of past moving average and not future ones :
p=14
avg=average[p](customclose)
r=round(p/2)+1
b=customclose-avg[r]
myDPO=b
RETURNmyDPOas"Detrented Price Oscillator of past datas",0coloured(10,10,255)as"0"
Bonjour, malgré mes nombreuses tentatives, je fais choux blanc.
Mon but est de rendre opérant les “DARVAS BOXES” en temps réel, et non pas en “statique”, et je n’arrive à intégrer le bout de code que tu m’as transmis ci-dessus dans le code original.
Merci pour ton aide, si cela est possible bien entendu.
Victorio je ne pense pas qu’il soit possible d’obtenir les mêmes box comme ça. Même si je suis d’accord avec le bout de code à insérer de Nicolas pour représenter le dpo avec les moyennes mobiles passées, il suffit d’afficher le dpo existant de PRT et de cocher tour à tour “utiliser les moyennes mobiles passées”/”utiliser les moyennes mobiles futures” pour voir que ça donne des dpo vraiment très différents. Et ensuite dans le code de Darvas box les différences dues au dpo se propagent comme une boule de neige en créant des différences encore plus grandes dans le calcul de hi et lo. Il en résulte des box très différentes.
Enfin, si je puis me permettre, dans l’insertion du bout de code de Nicolas sur le dpo, tu as un “customclose”, qui te laisse librement choisir en fenêtre de l’indicateur si tu veux l’appliquer à high , low, close, autre… Mais dans le code de Darvas box tu as 2 fois un calcul de dpo avec du high et avec du low. Or si tu laisses customclose comme tu l’as fait, et qu’après en fenêtre tu choisis high, tu vas calculer 2 fois en high (respectivement si tu choisis low tu vas calculer 2 fois en low), ça va créer des erreurs qui vont s’ajouter aux différences dues au mode de calcul des dpo. Donc tu dois adapter le code de Nicolas en traitant 2 calculs séparés de dpo, un avec high, et un autre avec low. En remplaçant le p de Nicolas par pprc pour pas confondre avec le p déjà pris dans le code de Darvas box et faciliter la lecture des 2 codes fusionnés, ça donnerait quelque chose comme ça:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
rem from hk_lisse blog
k=48
oncetth=undefined
oncettl=undefined
n=(k*2)-4
p=(n/2)-1
pprc=n
avg1=average[pprc](high)
r=round(pprc/2)+1
myDPO1=high-avg1[r]
avg2=average[pprc](low)
myDPO2=low-avg2[r]
h1=myDPO1
moyh=high-h1
hi=(moyh-moyh[1]+(high[p])/n)*n
hi=(round(hi*100))/100
l1=myDPO2
moyl=low-l1
lo=(moyl-moyl[1]+(low[p])/n)*n
lo=(round(lo*100))/100
low1=(round(low*100))/100
high1=(round(high*100))/100
etc…
en ayant mis ici pprc = n puisque le code de Darvas box utilisait les n périodes pour son calcul, mais j’ai laissé pprc en intermédiaire pour éventuellement jouer avec en mettant pprc = plus ou moins que n et voir bouger les tailles de box. Mais je pense que la conclusion sera de toute façon que quel que soit le réglage, les box sont beaucoup moins pertinentes, parce que les dpo sont trop différents au départ pour que mathématiquement on puisse retomber sur les mêmes box.
.
