PRTBands : écarts entre Proscreener et Probuilder
Forums › ProRealTime forum Français › Support ProScreener › PRTBands : écarts entre Proscreener et Probuilder
- This topic has 5 replies, 3 voices, and was last updated 3 years ago by plopz0r.
-
-
11/21/2020 at 7:38 PM #151163
Bonjour,
J’ai testé un screener permettant de détecter un début de tendance en UT 1H via les indicateurs PRTBands. Or il semblerait qu’il y ait des écarts de valorisation des variables PRTBandsUp et PRTBandsDown entre les moteurs Proscreener et Probuilder.
Par exemple sur la valeur Gaussin (ALGAU), si je créé un indicateur défini de la manière suivante :
123456789101112131415bandsUp = PRTBandsUpbandsDown = PRTBandsDownIF upTrend THENIF close < bandsDown THENupTrend = 0ENDIFELSIF close > bandsUp THENupTrend = 1ENDIFIF upTrend THENupTrendLength = upTrendLength + 1ELSEupTrendLength = 0ENDIFreturn upTrendLength as "upTrendLength"La valeur qui m’est retournée est bien 1 sur la bougie du 20/11 à 17h00 comme il s’agit d’un début de tendance.
Si je teste le même script dans Proscreener, la valeur qui m’est retournée est 129 (comme s’il n’y avait pas eu de rupture de tendance depuis la bougie du 02/11 à 15h).
J’ai donc voulu vérifier pourquoi Proscreener n’était pas en capacité de voir qu’il y avait bien rupture de tendance sur la bougie du 12/11 à 13h par exemple.
En exécutant ce code :
12test = PRTBandsDown[58]SCREENER[1] (test as "test")J’obtiens une valeur de 5,597 contre 5,77524 sur le graphique. La clôture de la bougie se faisant à 5,735 il semble donc logique que Proscreener n’identifie pas la rupture de tendance.
J’ai essayé d’identifier d’autres actions qui pourraient être impactées par cet écart et il semblerait que seules les valeurs dont le pas de cotation est égal à 0,002 sont concernées (ex : $ALACT ou $MT).
Constatez-vous la même chose de votre côté ?
D’avance merci pour votre aide !
11/22/2020 at 10:40 AM #151191Il faudrait revérifier les valeurs entre elles en affichant une quantité d’unités proche de celle disponible dans ProScreener, soit 254 chandeliers.
Si les calculs de tendance commencent plus tôt sur le graphique, alors il est possible qu’une désynchronisation survienne. Je n’ai pas vérifier les exemples que tu observes cependant.
11/22/2020 at 6:23 PM #151233Bonjour,
Merci pour ton retour !
Comment limiter le nombre de chandeliers pris en compte ? J’ai essayé de le faire via la liste déroulante “quantité d’historique” et cela n’impacte pas l’historique pris en compte mais uniquement le nombre de chandeliers affichés à l’écran.
Je ne sais pas si cela est lié à une désynchronisation car il y a tout de même plusieurs ruptures de tendance récentes (< 254 chandeliers) qui ne sont pas prises en compte par Proscreener (cf screenshot en PJ).
Merci
11/25/2020 at 7:02 PM #151615Il y a l’instruction CalculateOnLastBars qui existe pour limiter la consommation de mémoire je ne sais pas si Nicolas parle de celle la mais je la donne au cas ou :
DEFPARAM CalculateOnLastBars = 200
11/26/2020 at 1:21 PM #151749uniquement le nombre de chandeliers affichés à l’écran.
c’est en effet ce à quoi je pensais, pour que le calcul de l’indicateur commence plus au moins au même moment que celui fait par ProScreener.
Il s’agit bien d’un compte avec données temps réel ?
11/26/2020 at 7:49 PM #151809 -
AuthorPosts
Find exclusive trading pro-tools on