J’y ai passé l’après-midi à tester, re-tester chercher le bug dans mon code au point de devenir fou…
Alors voilà, j’ai un code plutôt très long, à chaque fois que je change une chose, je vérifie que tout marche toujours comme il faut via des backtests. Et là je tombe sur un cas où il devrait prendre position et il ne la prend pas. Vérifications faites avec graph, j’ai une valeur de stochastique inférieure au seuil qui déclenche l’ordre. Mais contre-vérification faite dans une autre fenêtre où le code tourne en tant qu’indicateur, la même stochastique a une autre valeur! (même paramétrage, même “close” etc…)
Alors après avoir cherché un bug fantôme dans mon code qui aurait pu modifier la vraie valeur de ma sto, je fais une tentative radicale de recherche en dehors de tout élément de mon code.
Je suis en daily, je prends le paramétrage stochastique “par défaut” au lieu de celui de mon code, et je l’affiche 3 fois:
une fois en sélectionnant “stochastique” dans les indicateurs prt,
une 2e fois en le recalculant dans un indicateur a=stochastic[14,3](close),
et une 3e fois dans un probacktest de base (sans intérêt stratégique) qui achète ou vend selon la valeur stochastique, dans le but d’afficher via graph la courbe stochastique.
Et là paf! Que vois-je… que le stochastique est le même en tant qu’indicatur prt (1er affichage) et indicateur programmé (2e affichage a=stochastic[14,3](close), mais pas en probacktest ces derniers jours. Je remonte un peu dans le passé, là aussi valeurs différentes.
Du coup je remonte dans le temps au tout début de l’histo daily, mais là, mêmes valeurs. Je fais quelques points au hasard vers le début de l’historique, mêmes valeurs. Bref… par dichotomie je finis par trouver une discontinuité assez violente entre le 2 Novembre 2007 (mêmes valeurs) et le 5 Novembre 2007 (écart de 10 points entre des sto pourtant de même paramétrage qui n’ont aucune raison d’être différentes).
Est-ce que ça fait ça pour vous aussi? Ou bien est-ce mon processeur qui est sur le point de rendre l’âme. Mon code n’est pas en cause puisque j’ai réalisé ce test sans aucune des lignes de mon code, j’ai l’impression d’avoir trouvé un bug de la plateforme dans sa façon de calculer (ou de faire appel à des valeurs préstockées en mémoire) les stochastiques dans probacktest…
De mémoire, il y a aussi eu un topic sur le sujet dans le forum anglais. J’ai essayé de trouver la cause sans succès.
Je vais essayer d’en savoir plus cette semaine.. C’est assez troublant 😨
Merci Pascal de ton retour, je ne sais pas si ce sont des problèmes liés ou pas, en ce sens que sauf si j’ai lu trop vite, tu sembles parler de réinitialiser des éléments de ton code dans ton topic, et de différences entre le backtest et le proorder, alors que là mon test s’est fait en dehors de mon code et de toutes mes ut habituelles (à force de tourner en rond et ne pas trouver où j’avais pu faire une erreur, j’ai voulu tester uniquement la sto dans une ut simple) et je trouve une différence entre probuilder et probacktest (en amont donc de toute tentative de vérifier aussi si pro order et probacktests ont des différences). Possible que les problèmes soient liés, mais tant que tu testes avec ton code, difficile de conclure avec certitude si ça vient d’un bug du code ou d’un bug de plateforme.
Nicolas, pour info et illustrer avec des valeurs précises lors d’un test aisément reproductible par quiconque avec qui tu en discuteras:
1) stochastique 14,3 en daily en sélectionnant l’indicateur dans le menu: le 02/11/2007 = 55.93147 et le 05/11/2007 = 32.11225
2) en créant un indic pour vérifier par le calcul:
1
2
a=stochastic[14,3](close)
returna
mêmes valeurs pour le 02/11/2007 et le 05/11/2007 que ci-dessus
3) et enfin en créant le probacktest de base sans intérêt stratégique mais qui permet d’éliminer toute autre source d’erreur, dans le seul but de grapher la sto:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// Définition des paramètres du code
DEFPARAMCumulateOrders=False// Cumul des positions désactivé
// Conditions pour ouvrir une position acheteuse
indicator1=Stochastic[14,3](close)
c1=(indicator1<=1)
IFc1THEN
BUY1CONTRACTATMARKET
ENDIF
// Conditions pour fermer une position acheteuse
indicator2=Stochastic[14,3](close)
c2=(indicator2>=99)
IFc2THEN
SELLATMARKET
ENDIF
// Stops et objectifs
graphindicator1as"indicator1"
alors le graph donne aussi 55.93147 pour le le 02/11/2007, mais à partir du 05/11/2007 où on a ici 42.35642 au lieu de 32.11225, toutes les valeurs deviennent différentes dans probacktest de ce qu’elles sont dans probuilder
Si ça n’avait duré que sur quelques bougies, j’aurais cru à une simple erreur de données, de type un high cfd absurde corrigé dans un flux principal mais pas dans une série de données parallèles utilisées pour le probacktest, mais vu que ça s’éternise bien au-delà des paramètres de sto utilisés, c’est autre chose qu’un simple high ou low erronné de ci de là…
De plus j’ai essayé d’autres paramètres de sto, mêmes conclusions…
Je pense qu’on a mis le doigt sur un bug probacktest pas banal (qui n’est pas lié au classique débat des targets testées avant les stops dans une même bougie) qui potentiellement fausse a minima les backtests de tous ceux qui utilisent n’importe quel paramétrage de stochastique en daily, et au pire, qui faussent ceux de tout le monde si c’est une histoire de mauvaise source de données pour calculer quelqu’indic que ce soit dans n’importe quelle ut de probacktest… (je n’ai pas vraiment poussé la recherche pour d’autres indics et d’autres ut, c’était déjà assez fastidieux comme ça de se taper le daily pour trouver où ça a dérapé, quand j’ai trouvé j’ai posté ici, tout en éprouvant des mixed-feelings à la fois soulagé de trouver, et déçu de ce que ça implique pour la [non-]validité potentielle de tous mes backtests précédents.
Ou alors j’ai un bug dans mes tests du genre gros comme le nez au milieu de la figure et je le rate…
Correction: en faisant d’autres tests au hasard pré-02/11/2007, il y a de temps en temps des fois où on a une toute petite différence de 0.00001, exemple 02/06/2006 avec 41.80592 (probuilder) et 41.80591 (probacktest) ça semble être juste une histoire d’arrondis sans importance comme ça, mais étant donné le contexte de comprendre si c’est bien novembre 2007 que ça a dérapé, ça pourrait aussi être un indice d’une erreur encore plus en amont…
En fait je n’avais pas identifié le problème quand j’ai posté le screen montrant un décalage important d’un trade prit par le même code en backtest et Prooder.
Mais j’avais bien le même doute que le problème était autour du calcul de l’indicateur (pour moi, le SAR). C’est pourquoi comme je l’ai dit j’ai récrit un code simplifié pour apporter du biscuit. Je fais donc tourner le même code sur 10 stratégies en UT seconde depuis quelques jour et je posterai si l’anomalie se répète (pas eu le temps d’étudier).
Le bug que j’ai relevé à savoir le calcul erroné d’intradaybarindex toujours sur cette UT seconde ne concerne pas le screen partagé puisque il n’aurait tout simplement pas prit de position si mon système ne s’était pas réinitialisé. C’est pourquoi ton expérience renforce mes doutes, qui comme tu le soulignes peut avoir de grosses conséquences. Pour l’instant je ne peux que la soupçonner d’être bien aussi présente sur Proorder…
Je n’arrive pas à retrouver le sujet dans l’autre forum, ou alors c’était dans celui Italien? je continue à chercher, c’est assez récent je dirai. J’aimerai bien le retrouver pour étayer votre retour, merci.
C’est possible que ce soit sur le forum italien que je ne suis pas, car ça ne me dit rien et sur le forum anglais que je lis régulièrement je crois que je l’aurais vu passer si c’était récent.
Ou alors tu penses en fait au topic du forum français proscreener “valeur fausse retournée par un indicateur” qui semblait être un bug dans proscreener? Pas exclu que les 2 problèmes soient liés dans le cas où probacktest et proscreener auraient le même type de bug?
Je ne pense pas que le problème vient de là car j’ai assisté aujourd’hui en live sur ProOrder, à un trade où la seule condition était “close < SAR then short” mais le short a été prit trop tôt alors que les bougies étaient vertes et qu’en backtest, le code n’avait pas encore shorté.
Nicolas, pour le moment je n’ai pas envoyé de message sur ce sujet à PRT puisque tu semblais vouloir tenter d’en savoir plus dans la semaine. As-tu eu la possibilité d’en discuter avec eux? Ou bien si tu es trop occupé avec tes développements en cours, je peux peut-être les informer de ce problème de stochastique dans probacktest, via le menu “aide/service technique” du logiciel, avec lien vers ce topic, pour qu’ils se penchent sur la question? (nb: et ce, même si je ne suis pas sûr que le message leur parvienne bien directement sans qu’IG filtre au vu de certaines réponses à couleur davantage “commerciale” que “technique” reçues certaines fois précédentes où j’ai fait usage de cette façon de rapporter des problèmes techniques)
Je pense que ton problème pourrait être régler facilement si tu ré-affiches les données du week-end. Lorsque l’on cache ces données, cela n’affecte pas ProBuilder, mais ProBacktest oui.
Tes différences ne viendraient tout simplement pas du spread et/ou du slippage ? Si tu penses que non, alors il faudra ouvrir une console de debug et l’envoyer à PRT pour qu’il regarde de plus près ton problème.
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
.
.
