TakaPeek3 2019 : récupération de l'historique des ticks IG

Où est le HS ?

Qu'est-ce qui est faux dans ce que je dis ? Dis donc tu jettes un peu vite le bébé et l'eau du bain, je trouve.

J'ai vite parcouru alors je ne sais pas si c'est hors sujet ou non, mais j'ai déjà exploité en réel des robots de trading qui marchaient très bien (techniquement s'entend) sur une longue période, avec le flux chart:tick.

De plus, si on construit des bougies minutes avec les ticks récupérés, qu'on y ajoute de la transparence avec photoshop, on peut voir qu'elles se superposent très bien avec les bougies du graphe ig.

Je pense donc qu'il est tout à fait possible de trader avec ces flux, en sélectionnant des stratégies assez robustes pour n'être pas sensibles au tick près.

Effectivemetn taka. Si un algo a une prise de décision sur une cloture de Bougie, le nombre de tick "dans" la Bougie est finalement très peu important.

Bon tout ça me motive à redebuguer l'API privée de la profit factor web d'ig. J'ai une démo qui se log mais ensuite le flux LS est vide et depuis ... pas eu le temps de faire avancer.

- - => Ma pierre à l'édifice.

J'ai passé des milliers d'ordres via l'API d'ig en utilisant le même flux que celui streamé par Takapeek. Zéro soucis là dessus. Pas de surprises. Ça fonctionne du tonnerre. Très peu de rejets (toujours explicables ex-post, peu importe la nature).

Si tu passes des OL alors le tick qu'il arrive ou pas chez toi n'as aucune importance. Il faut qu'il soit présent chez le brocker.
J'ai déjà bvécu des positions fermé alors que le tick n'as pas été présent sur les flux/graphes d'ig.. En fait C'est du au algo d'ig pour transformer le flux du sous)jacent en flux "cfd à risque limité". ça joue à 0,1 voiur 0,5 en fonction de la valeur de l'indice.

Mais ce qui m'étonnes c'est de vouloir "voir" le tick, pour un OL ça n'a pas d'importance. Les ordre sontg 100% executé et traité chez ig pas chez toi. (et heureusement).

A l'époque de la L3, et de tous les utilisateurs il y a eu des milleirs d'ordres passé chez ig. Le constat était qu'entre l'envoi de l'ordre est le retour de "prise en compte par ig" était au minimum de 100ms. Dur de descendre en desous. et de toute façon si tu descend en dessous ig a une protection qui empeche les ordres en mode mitraillettes.

Et bien je te dirais que de mon expérience ce que l'on voit arrivé sur nos PC n'est pas utilisé par ig pour l'execution de nos ordres. Point barre. Tu devrais relire les réponses ça te ferai du bien. Mais bon comme il faut toujours répéter je vais me répeter encore une fois :
ig ne reproduit pas 100% des cours du sous-jacent dans ses tick/graphes. il arrive donc (de très rare fois ça doit se mesurer en 99,9999%) d'avoir une ordre executé alors que sur ton graphes ça ne devrait pas.

Donc si tu utilises un OL, tu fais 100% confiance à ig sur le fait de ton exécution (ça je pense que tu le sais bien). Une fois que l'on a dit ça, et à moins d'avoir besoin d'un niveau vu une fois pour lancer un OL mais ça ne semble pas être ton cas, je ne vois pas le problème ni le rapport entre ton interogation sur les OL et les tick.

Et pour info, relis : je n'ai jamais parlé de spread dans mes derniers message, tu me fais peur par moment.

Quel était le flux utilisé chez ig dans le processus d'éxecution des ordres (flux de ticks ou flux market price) ?

Je dirais ni l'un ni l'autre car tout se fait en backend avec les flux reçu des bourses. ce que nous recevons c'est un flux transformé qui ne sert pas à l'execution des ordres (et ne servira certainement jamais à ce besoin).

Et quand j'ai vu que mon ordre avait été fermé alors que sur les graphes on avait pas vu mon prix ... aussitôt appel au desk ... et là j'ai eu l'explication technique. Enfin y'a rien de secret, maintenant là on est dans des niveaux de détails qui sont de d'intéresser M. et Mme Michu.

à mon humble avis tu vas trop loin dans le détail, c'est pas là que ça se joue.

Je pense que tu as besoin de lire (relire ?) cette page : https://labs.ig.com/apiorders

la différence entre les flux : je me suis posé la même question il y a quelques années. En fait c'est un peu comme les flux "tick tick" ou "cadencé" dans prt. (et il y un troisième niveau, mais par exemple, le flux "tick tick" n'est pas possible si tu es caché derrière un proxy sur prt ...)

Si tu as un bon accès internet (débit, qualité, ...) alors tu prends le tick, sinon tu reste sur le flux pulsé qui est moins consommateur de ressources.

Ce n'est que mon interprétation.

mais c'est fou cette propention que tu as à relancé les débats alros que c'est une erreur de lecture.
" tick tick ou cadencé" = je parle du mode dont tu configures ton prt pour recevoir ton flux ...

Décidément dur dur la communication.

Spoiler:

Tu n'aurais pas tendance à lire trop vite ?

up-2,5.jpg (13.91 Kio) Vu 667 fois

tu me désespères ... si tu es content avec ta réponse ... alors ça me va.

Spoiler:

ce qui me desespère, dans ta communication, ce n'est pas le fait technique ou ta franchise, mais c'est ta façon de lire trop vite et de toujours te poser en sachant ... ce qui fait que l'on a tjrs 50 message d'échange quand un ou deux aurait suffit.

Alez retourne sur ton cron et trouve pourquoi le user "toto" ne peut pas lancer, il y en a qui aimerait bien lancer ses curl

Je vais essayer de corriger ce matin !

Les corrections sont faites.
Il faut attendre un peu qu'elles soient répercutées dans le cloud Dropbox.
J'homogénéiserais les dates plus tard.

C'est l'heure de Paris

Précisions sur les dates :

Les dates sont toutes générées au format YYYY-MM-DD

Mais si on ouvre le fichier CSV dans Excel et que, pour une raison quelconque, on le sauvegarde, les dates sont basculées par Excel au format DD/MM/YYYY.

J'avais fais cela pour quelques fichiers : il sont maintenant corrigés.

Précisions sur les heures :

Les fichiers extraits par TakaPeek3 contiennent les 3 types d'heures suivantes : Paris, UTC et Locale.

J'ai volontairement généré les fichiers finaux avec l'heure de Paris pour que :

- Chaque fichier historique commence toujours à 00h00 et non à 02h00 ou 01h00 suivant la période de l'année

- Les ticks historiques soient conformes avec l'affichage des plateformes ig ou prt afin de faciliter les comparaisons graphiques

- L'heure des ticks historiques correspondent à l'heure réelle du jour lors de l'exploitation des stratégies en réel.

- Dans les programmes de backtest, il soit plus facile de déterminer la fin et le début d'une journée

- On puisse facilement élaborer des stratégies tenant compte du moment de la journée sans s'embêter à effectuer des conversions pour chaque heure

Oui, c'est bien l'heure de Paris pour tous les fichiers, y compris les fichiers d'instruments différents (c'est pour faciliter le développement de stratégies multi-instruments)

Les fichiers extraits par TakaPeek3 ne sont pas directement stockés comme historiques.

Comme il peut y avoir plusieurs sources (plusieurs membres qui récupèrent les ticks avec TakaPeeks), ils doivent d'abord être fusionnés.

C'est lors de cette fusion que seule l'heure de Paris est conservée.

J'ai ajouté les autres timezones pour ceux qui voudraient exploiter TakaPeek3 et qui ne seraient pas en France ou qui voudraient l'heure UTC (comme toi).