Vue x ticks et changement de semaine

Forums ProRealTime forum Français Support plateforme ProRealTime Vue x ticks et changement de semaine

Viewing 15 posts - 1 through 15 (of 20 total)
  • #4514

    Bonjour,

    J’utilise beaucoup la vue x ticks pour du trading allant de l’intraday au swing de quelques jours en CFD avec PRT et flux IG du France40, et souvent (déjà 6 fois en 13 semaines depuis le début de l’année) alors que tout allait bien sur le graphe le vendredi soir en clôture de semaine, le lundi matin qui suit on “perd” les données x ticks du vendredi précédent et le graphe affiche un “gap” du jeudi soir au lundi en vue x ticks, alors qu’il n’y a aucun problème avec des UT minutes/heures/etc… cela ne concerne que les vues x ticks quel que soit x.

    J’ai aussi PRT et flux Euronext pour le CAC40 mais là le problème ne se pose pas, je crois que c’est un problème qui ne doit concerner que les CFD et le passage d’une semaine à l’autre. J’imagine que c’est lié à la gestion de la cotation CFD qui commence le dimanche minuit, et que toutes les données du vendredi se retrouvent “absorbées” dans le weekend et/ou la cotation nocturne du dimanche au lieu d’être considérées comme appartenant au vendredi, mais bon je ne suis pas développeur donc je n’en sais rien. Un autre indice qui me pousse à penser que c’est lié au changement de semaine, c’est qu’avec ce weekend de Pâques il n’y avait pas de cotation CFD du France40 vendredi, et ce matin la vue x ticks du France40 se retrouve amputée des données du jeudi 24 mars, soit le dernier jour de cotation de la semaine dernière.

    A chaque fois que ça se produit, j’envoie un message via PRT dans le menu “aide / support technique” et le message semble en fait arriver au service commercial d’IG, qui m’envoie alors un email pour dire qu’il en informe le service technique. Ce que je ne sais pas, c’est si c’est un service technique d’IG ou un service technique de PRT, ou même les deux mais l’un après l’autre. IG ne me prévenant pas de la résolution du problème, je me retrouve à relancer ma plateforme PRT plusieurs fois par heure presque tous les lundis jusqu’à ce que “mon vendredi précédent” réapparaisse sur le graphe dès que le problème est résolu, et ce surtout pour retrouver enfin l’usage normal de mes indicateurs qui restent faussés tant que le problème n’est pas résolu (à de rares exceptions près pour les x très petits et périodes très petites des indicateurs ).

    Je suppose que c’est quelque chose qui ne dépend pas d’attendre “une nouvelle version”, car à chaque occurrence de l’incident les données sont rétablies dans les 24h qui suivent mon message. Ce que je ne sais pas, c’est si c’est un problème qu’il appartient à IG seul de résoudre, ou si ça appartient à PRT mais qu’IG ne fait pas suivre mes requêtes pour résoudre ceci de façon permanente au lieu de dépendre un lundi sur 2 d’un client qui se rend compte du problème de données pour prévenir.

    Vu qu’IG ne me répond pas sur le sujet et que je viens de découvrir ce forum ProRealCode, je tente d’évoquer le problème ici en espérant ne pas être hors-sujet (mes excuses si je le suis), car il serait rassurant de savoir que quelqu’un travaille à une solution permanente plutôt qu’à une réparation poncutelle chaque lundi plusieurs heures après l’ouverture.

    #4526

    Bonjour Noobywan, je vais essayer de récupérer des informations à ce propos et je reviendrai vers toi.

    #4531

    Sympa merci,

    Dans un premier temps j’ai cru que ce forum était un forum “officiel” appartenant à PRT et que tu en étais le modérateur de PRT pour interagir avec tous les utilisateurs, mais en le parcourant un peu plus en détails, dis-moi si je me trompe mais c’est en fait ton site et forum privé et tu es un utilisateur “PRT-enthusiast” comme nous sans lien salarié avec PRT c’est ça? Excuse-moi pour la méprise si c’est le cas, mais c’est en fait un compliment pour ton site, il est tellement bien fait que j’ai cru à une nouveauté officielle de PRT.

    Je ne voudrais pas te faire perdre du temps avec ça surtout si jamais il s’avère que le problème est purement chez IG plutôt que PRT. J’ai trouvé une page de contact (https://www.prorealtime.com/fr/contact) à qui j’ai envoyé le même message que ci-dessus. Si j’ai une réponse de PRT je la mettrai ici, ça pourra éventuellement interesser d’autres qui ont constaté ce problème en x ticks aussi.

    #4576

    En effet, je ne suis pas salarié de PRT. Tout est “homemade”, mais j’ai des contacts et on m’aide un peu 🙂

    Pour ton problème de FRIDX :

    Concernant le FRIDX, ce souci de spike n’est maintenant plus visible en production. Les cotations en temps réel sont revenues à la normale.

    #4583

    pour participer a se sujet: utilise aussi les vue en TICK pour les futures CME et EUREX ansi q pour le FOREX.

    en se qu’il concerne les contrats futures je trouve se problème de tamp en tamp ainsi q autre problème similaire comme les points pivot qui se pose sur un niveau x a la fermeture des marches usa pour ensuite changer de positions a la cloture de la journée calendrier ///de la meme façon la bougie journalier change sa cloture et devein différente…    par contre le marché du forex qui na pas heure de cloture en semaine-linformation reste impeccable/

    ceci donne a croire q les marchees avec overture et cloture journalières uniquement soufre de c petits divergences -se sera une possibilité de verifier ceci a vos contrats cfd et peut être adapter un différent horizon de tamp????/

    #4584

    Pour le Fridx, je confirme, aucun soucis aujourd’hui et les spikes des jours précédents ont disparu 🙂 C’est le jour et la nuit

    Merci Nicolas et merci l’équipe de développeurs PRT 😉

    #4632

    Merci Davex770, en fait j’utilise simultanément plusieurs fenêtres avec différentes UT (surtout des x ticks) et je les préfère aux UT temporelles (minutes heures etc…) tant qu’on est inférieur à UT day, parce que ça me permet d’inclure les cotations nocturnes des CFD sans leur donner une importance démesurée, et ce pour tenter de déterminer si un high ou un low est fait la nuit sans pour autant perdre “le poids” des cotations de la veille car il y aura très peu de bougies x ticks nocturnes, alors qu’il y aurait beaucoup trop de bougies nocturnes avec une UT temporelle. Et je simule l’UT supérieure dans mon algorithme en augmentant les périodes de mes indicateurs, c’est pourquoi dès qu’il me manque “un jour” en x ticks, même s’il est présent en UT temporelles, ça me fausse toute simulation de l’UT supérieure qui a besoin des cotations de la veille, et juste changer d’horizon de temps ne contourne pas le problème, car je suis sur plusieurs horizons de temps à la fois. Espérons que la correction apportée cette semaine par l’équipe de PRT sur un serveur dont nous a parlé Nicolas résoudra définitivement le problème.

    Merci Nicolas, j’aime beaucoup ton site, avec ta permission je me permets de rajouter un lien vers ton site sur mon blog dans ma rubrique “liens utiles”

    #4635

    Noobywan, tu peux mettre autant de liens que tu le souhaites vers ProRealCode où tu en as envie 🙂

    Tu peux me fournir un lien vers ton site en privé à nicolas[at]prorealcode.com , merci.

     

    #4639

    pour rajouter au sujet: lhistorique vue e nX TICK  et vraiment limiter sur la plateforme . en tamp q utilisateur de la version premium j pu étendre cette historique bcp plus q le minimum de la version basic. sinon impossible effectuer un backtest suffisamment long pour des configuration et strategy/   en effet je me rend compte parfois sur les divergence entre les ticks en tamp reel et leur representation de nouveau une fois la plateforme redémarrer-ces peut être lier au meme point q tu present dans se post.

    un point encore plus intéressent: les marchees tell q les futures ou actions sont centraliser et donc la liste tick par tick ainsi q les volume doive être normalement unique. cependant-je travail sur plusieurs plateforme différent dont la prorealtime ‘et c bien étonnant : la representation en X TICK news jamais similaire! il y’a toujours des différence remarquable et importants. ni la taille des bougies ni leur forme ni le moment de changement de bougies. et cela peut import combien de ticks en vue 233/ 1233 ou 5000

    esc qqun a une idee dexplication de se phénomène?

     

     

     

    #4641

    @Davex770

    Un historique de graphiques en ticks, c’est un vrai trésor pour un courtier, c’est du BIG DATA qui vaut de l’or, c’est pour cela que l’historique est bien plus important en Premium.

    En représentation X ticks c’est normal qu’il y ait des différences, car les graphiques en ticks sont construits à la volée en fonction du nombre de ticks que tu souhaites avoir dans une bougie.

    Par exemple, si tu veux une construction en 233 ticks, le logiciel utilisera une façon différente de construire les bougies que de celle qu’il utiliserait si il devait construire des bougies de 230 ticks (chiffre rond), tout cela dans un soucis d’optimisation d’affichage et de performance.

    #4647

    merci nicolas pour ton post et merci pour le forum et le site encore:

    je reformule ma question: biensure entre 233 ticks et 133 ticks doit avoir une différence ces logic…

    ma question et la divergences des representations entre les plateforme:

    quand je fix une vue de 500 ticks par exemple sur les trois plateformes q utilise: chaque plateforme représente les bougies complètement différent de autre.

    a se moment la ou je vous écrit je vision le future DAX en representation de 1133 ticks sur trois plateforme/ le prix et bineuse identique sur les trois ainsi q les variations. par contre le moment et décompte des ticks et complètement différent: la prorealtime par exemple bien de terminer une bougie bousille sans ombre tendue q la deuxième plateforme et toujours en plain de décompte de la bougie et il lui reste plus de 300 ticks   …. la troisième plateforme bien aussi de terminer la bougies 30 second plus tard et du coup comme le marché et descendue impeut donc la bougies possède un ombre important/

    si ceci arrive dans un marché descntraliser comme le forex -ceci et complètement comprehensible/ par contre dans les marches centraliser- ma logic me dit q de la meme façon q le prix  ainsi q les donee de open high close low etc etc et toujours identique-les ticks qui représente le nombre de transactions doivent être de meme identique. esc je me trompe?

     

    #4652

    Quand tu regardes du 500 ticks sur le même produit mais 3 plateformes différentes, est-ce que “l’origine” de l’historique x ticks est 3 fois le même aussi? Par exemple une plateforme avec historique qui démarre ce jour, et une autre avec historique qui démarre début de semaine, alors il est assez probable que sur la 2e plateforme, la dernière bougie 500 ticks à avoir une open hier aura sa close aujourd’hui mais pas forcément une close simultanée à l’open de la toute première bougie de la première plateforme dont l’historique démarre aujourd’hui (et de même on peut imaginer qu’une 3e plateforme avec historique encore plus long n’aura pas une close de bougie 500 ticks simultanée à l’open de la première bougie de chacune des 2 autres plateformes). Donc les décalages “en live” seraient représentatifs du décalage des origines d’historiques de longueur différente.

    Si par contre tu as pour le même produit 3 historiques de même origine, là je ne vois pas.

    #4653

    Sur ProRealTime, tu peux régler la qualité du flux selon ta connexion également comme sur l’image ci-joint. Cela “aurait peut être” un impact ?

     

    #4655

    noobywan

    merci pour ton post mes bineuse jetais  la premier chose q j verifier… je ne c toujours pas la source de cette divergence je viens adresser la question a un amie qui travail chez CQG et qui et un expert en data et plateforme électronique

    nicolas merci pour ta proposition- jésus depuis toujours brancher sur le flux le meilleur des trois  et cette divergence exist meme quand je me concert via mon serveur de colocation qui a une connexion de haut qualité et stabilitee

    donc jetant avoir impeut plus information et je vous f savoir ici si sa porte des fruits//

    merci

    david

    #4733

    Bonjour,

    La conversion Unités Temps en (x) ticks

    J’ai chercher partout sur le web mais en vain je n’ai pas trouver.

    Pouvez vous m’aider à mettre chaque (x) ticks sont Unités Temps les valeurs ticks officiels qui correspond.

    C’est à dire: 1 seconde = ? ticks – 1 minute = ? ticks – 1 heure = ? ticks

    exemple: https://www.prorealtime.com/fr/x-tick-et-tick-par-tick

    1 minute = 100 ticks

    5 minute = 200 ticks

    2 heure = 2000 ticks

    ——————————————————————-

    A compléter

    1 seconde = (1000 millisecondes) = ? ticks

    1 minute = (60 secondes) = 100 ticks

    2 minute = (120 secondes) = ? ticks

    3 minute = (180 secondes) = ? ticks

    4 minute = (240 secondes) = ? ticks

    5 minutes = (300 secondes) = 200 ticks

    10 minute = (600 secondes) = ? ticks

    15 minute = (900 secondes) = ? ticks

    30 minute = (1800 secondes) = ? ticks

    1 heure = (3600 secondes) = ? ticks

    2 heure = (7200 secondes) = 2000 ticks

    3 heure = (10800 secondes) = ? ticks

    4 heure = (14400 secondes) = ? ticks

    merci pour votre aide

Viewing 15 posts - 1 through 15 (of 20 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login