Programmation PRT

Bonjour à tous, je suis nouveau sur ce forum (ps: je ne trouve pas l'endroit pour se présenter je crois que c'est obligatoire)

Je voudrais créer un backtest dans prt sur le break out du +haut ou +bas de la 1ére Bougie ut 15min (entre 9h00 et 9h15)

J'aimerais savoir si certain peuvent m'aider à programmer ce backtest si prt le permet.

merci.

Bonjour cola.
Tu dois te présenter ici:
presentation-des-membres.html
si tu veux obtenir des réponses.

ben oui bien sur tu peux programmer tout ce que tu veux il n'y a pas de limte ceux ton imagination

Mon problème c'est comment mentionner une Bougie en particulier (ici la Bougie entre 9h et 9h15) dans prt.
Il est tjrs question de la nième Bougie par rapport à la Bougie en cours

(La limite pour moi, c'est que la plate-forme soit en java, ça ma refroidi très vite pour toutes les velléités de programmations très poussées dessus. Java est un langage dit de haut niveau, loin du langage machine. Donc si on veut faire des programmes très lourd en traitement faut vraiment éviter, à mon avis.)
En faite je n'avais pas besoin de préciser ça. Si on code ce genre de programme on le sait. Et pour trader on peut parfaitement s'en passer.

Sinon pour les programmes légers, normaux, c'est mieux car plus facile et rapide à programmer.
Je suis d'ailleurs agréablement surpris par sa vélocité et la qualité de réactivé du fux; les amis qui codent ça sont bon.

Je ne connais pas trop la programmation prt mais on doit pouvoir faire un truc du genre if (conditions sur barre[0]) and (currentime=9H15) then ...

oui c'est évident, ou un truc qui s'en approche.

(La limite pour moi, c'est que la plate-forme soit en java, ça ma refroidi très vite pour toutes les velléités de programmations très poussées dessus. Java est un langage dit de haut niveau, loin du langage machine. Donc si on veut faire des programmes très lourd en traitement faut vraiment éviter, à mon avis.)

Il y en a d'autres, de limites. En particulier, des bugs sur certains indicateurs qui retournent la mauvaise valeur. Malheureusement, l'équipe de développement est peu réactive.

barindex = la nième Bougie présente sur ton graphe, la Bougie la plu à gauche étant la numéro 1 (ou 0 je ne sais plus)
Intradaybarindex (ou approchant) = la nième Bougie de la journée. La premier Bougie a le numéro 0. Donc dans a série, si tu affiche 4 jours tu as 4 fois la Bougie 0.

Pour viser une Bougie en particuler tu peux utiliser un if avec un test de type if opentime = 90000 ...

merci pour vos commentaires
j'ai essayé ça mais je ne comprends pas pourquoi il continue de placer des ordre à d'autres niveaux


Defparam cumulateorders = false
Defparam flatafter = 171500

n=1

IF Time = 091500 THEN
maximummum = highest[1](high)
minimum = lowest[1](low)
achat = 1
vente = 1
ENDIF

if Time > 091500 AND Time <= 171500 THEN

IF achat = 1 THEN
buy n contracts mum stop
set target pprofit 10
ENDIF

IF vente = 1 THEN
sellshort n contracts AT minimum stop
set target pprofit 10
ENDIF

ENDIF

Kero > il semblerait que pour les comptes premium ils soient plus réactif.

y en a d'autres, de limites. En particulier, des bugs sur certains indicateurs qui retournent la mauvaise valeur. Malheureusement, l'équipe de développement est peu réactive.

De loin, voir même de très loin (car je n'ai jamais testé le dev sur la plate-forme de PRT, n'y vraiment beaucoup d'indicateurs dessus) quand je te lis Kero je pense directement à une erreur de ta pars.

Quand il y a un bug ça te renvoi rarement juste une mauvaise valeur. Mais un gros caca ou carrément rien du tout.

Regarde plus dans le paramétrage de l'indicateur et/ou du graph', si c'est un code perso' essaye de tester morceau par morceau séparément.

En espérant que mes évidences te servent

merci pour vos commentaires
j'ai essayé ça mais je ne comprends pas pourquoi il continue de placer des ordre à d'autres niveaux

....parce que tes variables Achat et Vente gardent la valeur 1. Quand la condition n'est plus vérifié la valeur doit changer.(else)

Kero > il semblerait que pour les comptes premium ils soient plus réactif.

Je m'en doute...

Kero > il semblerait que pour les comptes premium ils soient plus réactif.

y en a d'autres, de limites. En particulier, des bugs sur certains indicateurs qui retournent la mauvaise valeur. Malheureusement, l'équipe de développement est peu réactive.

De loin, voir même de très loin (car je n'ai jamais testé le dev sur la plate-forme de PRT, n'y vraiment beaucoup d'indicateurs dessus) quand je te lis Kero je pense directement à une erreur de ta pars.

Quand il y a un bug ça te renvoi rarement juste une mauvaise valeur. Mais un gros caca ou carrément rien du tout.

Regarde plus dans le paramétrage de l'indicateur et/ou du graph', si c'est un code perso' essaye de tester morceau par morceau séparément.

En espérant que mes évidences te servent

Il est vrai que je ne peux pas garantir qu'il s'agisse d'un bug, dans la mesure où je ne connais pas les "internals" (et pour cause, la doc est affligeante).

Maintenant, lorsque j'ai été confronté à ce problème d'indicateurs, j'avais quand même exploré le sujet, entre autre sur un forum de gens qui développent sur PRT. Je montrais des incohérences dans les valeurs retournées par les fonctions et même les amis du forum (parmi lesquels certains chevronnés) ne comprenaient pas. Ils me conseillaient de faire un rapport de bug à l'équipe de développeurs.

Ce que j'ai fait. L'équipe de développeurs n'a fait rien d'autre que me répondre que pour les indicateurs que je signalais, ils utilisaient des calculs différents (attention: différents de ceux utilisés par leur propre indicateur qu'on affiche au bas des graphiques. Du coup, j'avais un RSI retourné par la fonction du ProScreener qui était différent du résultat du RSI sous le graphique).

Or, pour certains indicateurs (genre RSI), cette histoire de calculs différents, ça n'avait aucun sens, il n'y a pas plein de manières différentes de le calculer. La formule est standard, seule les variables changent. Alors ensuite, à supposer qu'ils utilisent un autre calcul, moi je veux bien, mais qu'on m'indique lequel alors. Je ne peux quand même pas me fier à une fonction dont je ne sais même pas comment elle calcule le résultat, non ?

Je ne suis pas du genre à parler de bug dès qu'un truc informatique, ou un code que j'ai pendu, ne fait pas ce que j'attends. Je pars toujours d'abord du principe que l'erreur doit venir de moi (principe du PEBCAK, quoi).

Mais là, les réponses incohérentes à mes rapports de bug me montraient clairement qu'ils ne prenaient pas au sérieux mes remarques.

C'est d'ailleurs pourquoi j'ai un projet de développer mon propre outil, en C. Projet qui malheureusement, a du mal à avancer.

Si tu as un compte prt premium donc prt futures ou prt cfds à risque limité ils te répondent très vite et ils t'aident sans aucun souci.

Si tu es chez ig bink ou autres brokers divers et bien tu as le service light. Normal ton broker n'a pas payé pour que tu as le service premium. Tu n'as pas l'interface premium de prt tu as une version très allégée moins d'options, beaucoup moins de ticks et beaucoup moins de service. Tu as la version dite complète de prt bref une version light. Normal.

Donc si c'est des rapports de bug via ig ou autre ... tu as les réponses et le service light non prioritaire. Normal.

C'est comme chez ovh j'ai un serveur avec service premium j'ai un gars qui m'aide par téléphone et qui Check le serveur avec moi pendant 3 heures avec un temps de réponse dans les 5 à 15 Minutes pour intervenir. Un autre serveur non VIP j'attends une semaine une réponse de 3 lignes non pertinente copier coller et ils en ont rien à faire de moi. Pas le même service lol

Donc tu as le service qu'à payé ton broker à prt ni plus ni moins et ig a payé pour que tu as la version le support les outils light de prt si tu es chez eux.

D'ailleurs les amis qui font le backtesting ou du développement sur la version light avec un flux light moins d'options et 80% de ticks en moins sur certaines ut c'est de l'amateurisme ce n'est pas sérieux pour moi mais bon passons.

Et pour tes résultats sur le rsi c'est un peu normal. Tiens regarde cette vidéo tu auras la réponse ça se voit à l'œil nu les différences de ticks donc pour ton rsi valeur différente

faut-il-trader-avec-prorealtime-ou-la-v ... 14544.html

Un flux avec plus de ticks plus précis donnera des valeurs plus précises et ton rsi entre autres aura des valeurs très différentes entre deux versions retournées puisque sur un tu auras par exemple 500 références et sur l'autre 400 pour le même temps et voilà tes variables qui changent

tu le vois à l'œil nu sur la video je mets le rsi sur la même video et ton rsi sera pas le même et si tu compares en plus en live si tu n'as pas une connexion fibre tu as des erreurs fec qui te font perdre des ticks en réception. Sur certaines connexion ADSL éloigné du centrale même en ville c'est des millions d'erreurs fec parfois... on en a vu un sur le forum le mois dernier avec 100.000.000 d'erreurs fec. Tous ces graphiques sont faux et il mettait demo et réel pour comparer. Avec autant d'erreurs avec le même flux chez le même broker il avait des graphiques rsi etc totalement différents.

surtout avec la version 10.3 qui vérifie maintenant au tick tick pour le trading automatique l'exécution des ordres par exemple à l'intérieur de ta Bougie tu as intérêt d'avoir une version premium avec le maximummum de ticks à mon avis

Benoist, quand je parle du rsi, je parle du rsi en daily sur Cours de clôture actions. On n'est pas dans le monde des ticks infra-minute. D'ailleurs, on parle pas des cfd à risque limité actions, mais des actions réelles, sur leur interface EOD, avec les cours qui viennent directement des places de marché. Donc, ces problématiques n'interviennent pas à l'échelle dont je parle.

Le souci est que dans leur interface, le rsi de base (indicateur sous les graphiques) donne une valeur, alors que dans ProScreener, la fonction qui retourne le rsi retourne une valeur différente. D'ailleurs, eux-mêmes l'ont constaté, puisqu'ils me disent qu'ils utilisent un calcul différent, c'est juste que leur réponse n'a aucun sens. Le rsi ne se calcule pas de 30 manières différentes (ou alors il faut m'expliquer quelle autre formule ils utilisent, malheureusement, il n'y a aucune doc sérieuse décrivant les spécifications de leurs fonctions).

Je l'ai dit, j'en ai discuté avec des programmeurs habitués de prt et eux-mêmes constataient qu'il y avait un problème.

Après, moi je peux comprendre qu'en tant qu'utilisateur non premium, je ne sois pas prioritaire. Aucun souci à ça. Toutefois, en l'occurrence, je ne leur demandais pas de m'aider spécifiquement, je leur signalait un disfonctionnement de leur interface qui est susceptible de toucher toute personne utilisant le même outil. À partir de là, que je sois leur client ou pas, ça montre une attitude peu sérieuse, je trouve.

Accessoirement, faire un rapport de bug propre, circonstancié, avec des détails sur le problème, ce n'est pas rien: ça prend un certain temps à préparer. Je ne parle pas du rapport de bug modèle boulet (ouainnnn ça fonctionne pô), mais du rapport technique complet. Ce n'est pas pour rien que certaines boites donnent leur soft gratuit en version beta, afin de recueillir un maximummum de rapports de bugs. S'ils devaient le faire qu'en interne, ça leur couterait plus cher pour un résultat moins abouti. Donc, chez prt, à partir du moment où des utilisateurs se foulent à préparer tout ça pour eux, la logique (et leur propre intérêt) voudrait qu'au minimum, ils prennent ça au sérieux.

Benoist, quand je parle du RSI, je parle du RSI en daily sur cours de clôture actions. On n'est pas dans le monde des ticks infra-minute. D'ailleurs, on parle pas des cfd à risque limité actions, mais des actions réelles, sur leur interface EOD, avec les cours qui viennent directement des places de marché. Donc, ces problématiques n'interviennent pas à l'échelle dont je parle.

L'un empêche pas l'autre. Même si c'est évident que ça en amoindri l'intérêt de la quantité de perte de données, le faite que tu sois en daily, mais pas pour autant celles pertinentes !
Et pour la suite ça ne change absolument rien à une partie des propos de Benoist concernant les erreurs fec de ta connexion internet !

Après dans l'absolu je serais d'avis aussi que ça ne vienne pas de là.
En partant du principe que tu ais bien comparé l'intégrité des données pertinentes et/ou qu'ils se basent sur les mêmes données de flux.

Par contre je suis surpris que tu n'ai pas toi même codé un RSI classique pour le graphe de base et un autre se basant sur la même formule pour ProScreener, afin de comparer.

Surtout que c'est super easy et rapide à faire. Et là tu pourras vraiment avancer dans ton enquête sur le problème.
la formule -> https://www.andlil.com/le-rsi-250.html

Cola si tu ne met pas achat et vente à une autre valeur que 1 après 91500 il sera toujours à 1 donc tu aura des ordres sur chaque bougies.

Faut pas oublier que les variables gardent leur valeurs tout au long du programme :/)

Ecoute David, je suis pas un novice en informatique/programmation, et si j'ai constaté qu'il y a un problème, c'est parce que j'ai fait les checks nécessaires. J'ai d'ailleurs discuté du problème avec les amis de prt, leur réponse était juste simplement à côté de la plaque par rapport au problème observé. Ils n'avaient pas envie de se fouler, point barre.

Maintenant oui, j'aurais pu faire plein d'autres choses pour résoudre le problème, sauf qu'à un moment donné, j'ai d'autres occupations et à ce moment là, j'avais fini par lâcher l'affaire.

Au passage, mon problème de base n'était pas sur le rsi, mais sur un autre indicateur. En faisant des tests, j'avais simplement constaté que le problème se posait aussi sur le rsi.

Si tu es curieux des détails du problème: https://www.prorealcode.com/topic/valeur-fausse-retournee-par-un-indicateur/

tu es chez ig Kero ?

J'ai un compte ig mais pour prt, pas spécialement. J'utilise juste l'interface prt en mode EOD data, version complète et gratuite. Ça me permet de faire mes études sur action. Les cours sont directement ceux d'Euronext/Nyse et compagnie.