Bonjour à toutes et tous,
J’ai une question sur la profondeur de chargement d’historique sur les algos.
Je vais prendre l’exemple d’un algo Dax qui est mis sur UT 1 seconde. Dans cet algo, il y a un une partie MTF 30 minutes qui se base pour l’exemple sur une MM de 20 périodes (soit 600 minutes).
Ma question est la suivante : est-ce que l’algo va bien “chercher” toute l’historique nécéssaire pour charger les indicateurs, ou il faut attendre que l’algorithme tourne depuis 600 minutes pour que l’indicateur renvoie de “bonnes” données?
Car, quand je fais des Backtest en modifiant le nombre de barre sur le graphique, ça me fait varier complètement les résultats. Et en réel, j’ai des algos qui ne se déclenchent pas, alors que dans la “réalité”, les indicateurs devraient envoyer le signal de prise de position.
Merci d’avance pour votre retour.
Excellente journée.
Et du coup, est-ce que passer par l’appel d’indicateurs équivalents extérieurs via “CALL” modifierait quelque chose ?
Bonjour à toutes et tous,
Je relance un peu le post 😉
Je viens d’avoir un exemple de “problème” lié à l’historique de calcul d’indicateur:
Je calcule la différence entre la clôture de la veille et l’ouverture du jour. Si cet écart est inférieur à X%, ça me retourne 1, et si l’écart est supérieur à X% cela me retourne 2.
Dans le code, j’ai mis “DEFPARAM preloadbars=500000”
Si j’affiche 10k barres, l’écart me retourne 2. Si je fais un affichage de 100k barre, ça me retourne bien 1.
Et le problème, c’est que quand je démarre l’algol, il a la même “logique” que l’affichage 🙁
Je dois sûrement louper des choses, et ai besoin de votre aide.
Merci d’avance pour votre retour.
Bjr,
le max possible d’historique préchargé via defparam preloadbars au lancement d’un code dans le module proorder est de 10000 barres. Pour mm20x30 comme tu l’as dit ça fait 600mn, autrement dit 36000 secondes (et au-delà de ça en réalité il faudra plus de 36000s mais on peut en discuter que si besoin, car on a déjà largement dépassé 10000 de toute façon). Donc pas assez d’histo dispo au moment du lancement pour faire la mm20 ut30mn en ut1s.
Merci pour ta réponse JC_Bywan,
Une solution serait d’interdire la prise de position le temps que l’algol ai assez de data pour calculer les indicateurs ?
Y a-t-il d’autres choses à faire? Modifier la conception ?
Je reviens vers vous sur cette problématique de profondeur d’historique sur des algos en UT 1 seconde.
Imaginons que je fasse un algo basé sur les points pivots hebdo.
Si je lance l’algo le dimanche par exemple, aucun soucis si je permets d’intervenir à partir du lundi à 00h01 car les PP auront été calculés.
En revanche, si nous sommes le jeudi ou le vendredi (ou que je le relance manuellement), il sera impossible de calculer les PP hebdos car pas assez de profondeur?
Comment faire, si on souhaite rester sur cette UT ?
Utiliser l’instruction TIMEFRAME en allant chercher les infos dans un timeframe supérieur qui nécessiterait moins d’historique.
Si j’ai bien compris, cela veut dire que si je fais un bout de code du style:
TImeframe( 1 day)
calcul des PP
Timeframe (default)
le reste du code en UT 1s
Cela veut dire que même le vendredi j’aurais bien le calcul effectué (même si la profondeur sur UT 1s est largement “dépassée”) ?
Et donc, si je pousse la logique, si je veux charger les PP mensuel, pas de soucis si je prends la “Timeframe(1 month)” ?
Merci d’avance pour vos retours.
