C’est parce que ProOrder charge certaines barres avant la date de début que vous avez définie.
Ajoutez, comme ligne 1:
1
DEFPARAMPreLoadBars=0
Gardez à l’esprit que n ne sera plus effacé, donc votre stratégie (telle qu’elle est dans l’exemple) cumulera continuellement les achats après la première entrée.
Une PARSING ERROR signifie que lorsque ProOrder scanne les lignes a trouvé une erreur dans la construction d’une ou plusieurs lignes.
Votre code fonctionne bien sur mon graphique DAX, 1 heure.
On m’a renvoyé l’erreur “boucle infinie” dans la structure WHILE … WEND, j’ai donc ajouté une limite très élevée (il est important qu’il y en ait une) à la ligne 11:
Je viens d’essayer en mettant c < 100 et je n’ai plus de message d’erreur.
Je le fais fonctionner sur le DAX M1.
Par contre un ordre stop est placé dès la première lecture du code et non à la validation des conditions.
L’ordre buy stop a été placé au plus haut des 99 dernières bougies. Donc le code a d’emblé fait tourné la boucle c=c+1 jusqu’à sa limite 100 sans tenir compte de la condition RSI[14]<50, et placé l’ordre stop dès la première lecture sans tenir compte de la condition RSI[14] CROSSES OVER 50.
Vous ne pouvez pas utiliser DEFPARAM PRELOADBARS = 0 si vous devez accéder en arrière aux chandeliers.
Je n’ai pas pu trouver de solution au fait que N = 1 car RSI est calculé sur les barres préchargées.
De plus, votre ligne 10 (la ligne WHILE) compare toujours la même valeur RSI tout au long du nombre de barres que vous avez écrites, donc C sera toujours 99. Je vous suggère d’ajouter le paramètre facultatif CLOSE avec une référence à ses valeurs passées.
1
whilersi[14](close[c+1])<50andc<100do
En tout cas, si vous me dites exactement ce que votre stratégie veut réaliser, je peux penser à un moyen de la coder différemment.
La stratégie consiste en l’identification de toutes les bougies consécutives dont le RSI est > 50, ce qui inclue :
– la première bougie dont le RSI franchit à la hausse 50,
– toutes les bougies suivantes dont le RSI est >50
– la dernière bougie dont le RSI franchit à la baisse 50
A partir de ce groupe de bougie on identifie le plus haut et le plus bas, puis on place un ordre buy stop au plus haut et un ordre sell stop au plus bas.
J’ai rajouté DEFPARAM PRELOADBARS = 0 et j’ai encadré le code par IF BARINDEX > 14 then… ENDIF de manière à ce qu’aucun calcul du RSI[14] ne soit opéré avant le chargement de 14 barres.
Du coup l’ordre n’est plus lancé automatiquement dès la première lecture du code.
Mais une fois que la condition de franchissement des 50 par le RSI est observée je suis rejeté au motif PRELOADBARS pas assez d’historique disponible!
Comment se fait-il que le code ai besoin d’aller chercher dans l’historique alors que depuis le lancement du robot jusqu’à la réalisation de la condition il y a suffisamment de barres pour calculer tous les indicateurs utilisés??
Je ne sais pas si vous avez eu la possibilité de travailler sur le sujets.
Après 6 manières de coder différentes, j’ai trouvé une écriture qui lève tous les soucis rencontrés précédemment (problèmes de PRELOADBARS ou de passage d’ordre à la première lecture). Avec un RSI [14] comme indicateur j’attribue la valeur 15 à PRELOADBARS, et pour le comptage des bougies du range j’utilise BARINDEX et non plus une écriture qui est sensée s’incrémenter bougie par bougie. De plus je filtre les ranges composés seulement de 2 bougies.
Le comportement du code est déjà plus propre mais des positions injustifiées sont toujours prises par moment, je vais me pencher dessus.
Vous apports sur le sujet ou vos idées de codage me seraient d’une grande aide, merci par avance.
.
.
