Profondeur historique Algo UT 1 seconde

• 06/23/2022 at 9:38 AM #195923
  fxbravo

  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.

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
  06/23/2022 at 10:00 AM #195929
  fxbravo

  Et du coup, est-ce que passer par l’appel d’indicateurs équivalents extérieurs via “CALL” modifierait quelque chose ?

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
  06/28/2022 at 10:55 AM #196283
  fxbravo

  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.

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
  06/28/2022 at 11:15 AM #196285
  JC_Bywan

  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.

  

  JC_Bywan

  Moderator

  Topics: 20

  Replies: 2542

  Been thanked: 836 times
  06/28/2022 at 11:53 AM #196293
  fxbravo

  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 ?

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
  07/22/2022 at 10:27 AM #197693
  fxbravo

  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 ?

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
  07/22/2022 at 3:36 PM #197727
  Nicolas

  Utiliser l’instruction TIMEFRAME en allant chercher les infos dans un timeframe supérieur qui nécessiterait moins d’historique.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4738 times
  07/22/2022 at 4:41 PM #197729
  fxbravo

  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.

  

  fxbravo

  Participant

  Topics: 20

  Replies: 65

  Been thanked: 1 time
• Author
  Posts