J'ai besoin d'un bon fichier historique pour EURUSd - page 4

 

schnappi, naturellement la méthodologie pour identifier (et éventuellement remédier) aux mauvais ticks et aux trous de données est elle-même un processus évolutif. J'ai commencé par l'approche standard des filtres définis de manière externe (si le delta du prix > X alors nous avons un mauvais tick, etc.) et le problème avec cela est que vous forcez l'ensemble des données à se conformer à vos perceptions et attentes de ce à quoi les données de prix devraient ressembler, ce qui peut ou non être représentatif des caractéristiques statistiques intrinsèques de la dynamique d'évolution du prix de l'instrument financier.

Finalement, ma méthode a évolué jusqu'au point où j'exige simplement que les données soient cohérentes avec les caractéristiques intrinsèques de l'instrument financier lui-même (paire de devises dans cette discussion, mais cela s'applique à tous les domaines). En pratique, cela signifie que je prends une série de "bonnes données de marché connues" et que je caractérise de manière robuste leurs attributs : écarts temporels, écarts de prix, etc. Cela génère un profil d'évolution naturelle/caractéristique des prix pour la paire de devises (qui sera spécifique au courtier, car chaque courtier possède ses propres algorithmes subtils de "pompage et d'impulsion" pour maintenir le flux de prix "vivant").

Armé de ces données de caractérisation, je demande ensuite au script d'itérer à travers les périodes plus anciennes, plus discutables, en évaluant chaque barre pour savoir si elle est statistiquement cohérente avec la nature inhérente de la paire de devises. Par exemple, disons que nous observons que l'écart de prix qui se produit entre les bougies M1 successives pour l'USDJPY est généralement <3pips. En d'autres termes, l'offre de clôture de la bougie N+1 se situe généralement entre -3 et +3 pips de l'offre d'ouverture de la bougie N.

Il s'agit d'une mesure facile à générer, il suffit d'analyser la clôture (i+1)-ouverture (i) de vos données et de générer un histogramme : (notez que j'ai spécifiquement/intentionnellement exclu les écarts de prix qui proviennent de paires de bougies qui ont elles-mêmes un écart de temps entre elles pour cette phase de la caractérisation).


Maintenant, si vous évaluez les données historiques pour une année antérieure, disons 2003, et que votre script observe un écart de prix entre des bougies successives (sans écart de temps) qui est bien en dehors de la fourchette statistiquement cohérente (pour cet exemple, disons qu'un écart de 50 pips est détecté), alors votre script a des raisons de considérer les données de prix évaluées à ce moment-là comme suspectes.

Ce que vous faites avec vos bougies suspectes (la phase de remédiation) est une toute autre question, mais voici un exemple :


Il y a des dangers et des pièges à éviter dans la remédiation des données, vous pouvez involontairement causer plus de mal que de bien si vous n'êtes pas prudent dans la façon dont vous définissez votre liste d'éviction des mauvaises bougies ainsi que leurs remplacements (je considère simplement la suppression de la bougie de l'enregistrement hst comme une politique de remplacement aussi, remplaçant un mauvais écart de prix par un écart de temps artificiel dans ce cas).

 
Phillip, c'est intéressant, mais cela me semble trop risqué et trop long. Je préfère utiliser des sources auxquelles je peux me fier plutôt que d'essayer de "réparer" des sources auxquelles je ne peux pas me fier...

En ce qui concerne ces bougies "suspectes". De nombreux courtiers ont des pics de prix bizarres pour diverses raisons. Dans votre exemple ci-dessus, comment savez-vous qu'il s'agit d'une donnée "bad tick" évidente ? De tels pics peuvent arriver...
 
gordon wrote >>
Phillip, ce sont des choses intéressantes, mais cela me semble trop risqué et trop long. Je préfère utiliser des sources auxquelles je peux me fier plutôt que d'essayer de "réparer" des sources auxquelles je ne peux pas me fier...

En ce qui concerne ces bougies "suspectes". De nombreux courtiers ont des pics de prix étranges pour diverses raisons. Dans votre exemple ci-dessus, comment savez-vous qu'il s'agit d'une donnée "bad tick" évidente ? De tels pics peuvent arriver...


Re : comment savez-vous que c'est une donnée "bad tick" évidente... dans ce cas, avec ce courtier, une analyse détaillée de 3+ ans de données a montré qu'un tel pic ne s'est jamais produit, pas même une fois, sur plus de 1 million de bougies de données. Le rasoir d'Occam... qu'est-ce qui a le plus de chances de s'être produit à 04:29 le 2 août 1999 : le marché a fait un pic de 60pips, la bougie s'est fermée au sommet de la bougie et ensuite, le tick suivant marquant le prix d'ouverture de la bougie suivante, le marché est redescendu de 50pips et l'activité ultérieure du marché n'a pas eu plus de volatilité que les bougies précédant le pic ? Ou que cette bougie particulière contient un tick faussement mauvais qui peut être légitimement (avec confiance) éliminé ?

Vous remarquerez sur le premier graphique de mon post ci-dessus que, sur plus de 3 ans de données, la fréquence d'un gap de fermeture-ouverture dépassant seulement 4 pips pour cette paire est nulle. Dans ce cas, je me suis senti à l'aise de marquer la valeur aberrante de 50 pips comme étant une valeur aberrante évidente et de l'évincer de ma copie de l'historique des transactions.

Ence qui concerne les sources fiables par rapport au fixing... étant donné que vous ne pouvez faire confiance à aucun enregistrement historique pour le prix de vente lorsque vous utilisez une plateforme MT4, la notion même d'avoir des données historiques fiables par rapport à des données non fiables est vraiment une question de confort personnel à mon avis. Cela dépend bien sûr de votre stratégie commerciale spécifique. Dans mon cas, les spécificités exactes de l'historique ne sont pas pertinentes pour mon EA. Si une stratégie commerciale exige la précision et l'exactitude des enregistrements historiques pour être rentable, alors elle ne sera probablement pas rentable pour les positions courtes dans n'importe quelle paire de devises, car tous les prix de demande sont fabriqués dans le backtesting en supposant un écart fixe (qui n'est pas historiquement exact ou représentatif des conditions réelles du marché).

Donc, si vous voulez créer un EA suffisamment robuste pour faire face à la réalité des prix de demande fabriqués dans le backtesting, alors vous avez probablement créé un EA capable de faire face à des données de prix fausses ou erronées dans les enregistrements historiques. Je peux me tromper, ce ne serait pas la première fois, mais mon approche des données historiques consiste à les utiliser dans le but de rendre mon EA agnostique.

 
1005phillip:


Re : comment savez-vous qu'il s'agit d'une donnée "bad tick" évidente... dans ce cas, avec ce courtier, une analyse détaillée de 3+ ans de données a montré qu'un tel pic ne s'est jamais produit, même pas une fois, sur plus d'un million de bougies de données. Le rasoir d'Occam... qu'est-ce qui a le plus de chances de s'être produit à 04:29 le 2 août 1999 : le marché a fait un pic de 60pips, la bougie s'est fermée au sommet de la bougie et ensuite, le tick suivant marquant le prix d'ouverture de la bougie suivante, le marché est redescendu de 50pips et l'activité ultérieure du marché n'a pas eu plus de volatilité que les bougies précédant le pic ? Ou que cette bougie particulière contient un tick faussement mauvais qui peut être légitimement (avec confiance) éliminé ?

Ok, mais c'est un cas extrême. Et si c'était ~30 pips et que vous aviez 3 cas semblables dans toutes ces années de données. Comment savez-vous alors ? Ce que je veux dire, c'est qu'il y aura des cas où ce ne sera pas évident et où vous devrez deviner.


Re : sources de confiance versus fixing...puisque vous ne pouvez faire confiance à aucun enregistrement historique pour le prix de vente lorsque vous utilisez la plateforme MT4, la notion même d'avoir des données historiques fiables versus non fiables est vraiment une question de confort personnel à mon avis (...)

Mais ce n'est pas la question. Je parle de sources fiables que l'on peut utiliser telles quelles sans avoir à se donner tant de mal. L'absence de prix Ask (spread fixe) dans MT4 Tester n'a rien à voir avec cela puisqu'il affecte à la fois les mauvaises sources, les bonnes sources et les sources fixes... C'est un problème complètement distinct.

 

Phillip : À mon avis, c'est la voie à suivre. Je pense que les mauvais ticks peuvent être identifiés de manière assez sûre en analysant les sauts de prix en combinaison avec la volatilité suivante. Si le marché montre un pic et aucune volatilité anormale juste sur la barre M1 suivante, alors il y a de fortes chances que ce soit un mauvais tick. La capture d'écran que vous montrez ci-dessus est un tel exemple.

Vous avez déjà abordé le problème le plus important: définir les mauvais ticks est une chose - les corriger en est une autre. À mon avis, il y a deux façons de le faire.

1ère : identifier les mauvais ticks et les corriger en devinant. Si c'est l'ouverture qui s'écarte soudainement de +50 pips, alors ramenez-la à +3 pips et ainsi de suite. --> Ce n'est peut-être pas très précis mais facile à mettre en œuvre
2ème : identifier les mauvais ticks et comparer les prix avec un autre flux de données. Ce serait une méthode plus précise, mais beaucoup plus difficile à mettre en œuvre.

 

Gordon, j'évite de deviner en me basant sur les statistiques elles-mêmes pour obliger les enregistrements historiques à être cohérents. Je crois me souvenir que vous avez mentionné dans un autre message que vous étiez un trader axé sur les statistiques fondamentales. Vous comprendrez donc à quoi je fais allusion lorsque je dis que la prémisse est de minimiser la divergence de Kullback-Leibler entre l'ensemble de données suspectes et l'ensemble de données connues et bonnes (ce que vous appelleriez la "source fiable").

Dans le cas du forex uniquement, nous utiliserions la distribution normale généralisée au lieu de la distribution normale gaussienne, car l'aplatissement des marchés financiers est généralement supérieur à zéro. Je doute que je vous dise quelque chose de nouveau, mais je développe simplement les prémisses de ma méthodologie pour identifier et expulser les données suspectes avec confiance (le genre statistique, pas le genre machiste ;)) afin que vous sachiez que mon critère de sélection n'est pas quelque chose d'aussi simpliste (et défectueux) que de régler des filtres passe-bande haut/bas et de faire passer les données.

Naturellement, il y a des hypothèses concernant la stationnarité des données de prix de l'instrument financier sur la période de la "source fiable" lorsqu'on les traite comme un processus stochastique. Mais si je suis prêt à exiger de mes codes EA qu'ils limitent leur activité à des périodes de stationnarité équivalente dans les séries temporelles futures, l'autoconsistance est inhérente à l'approche. Puisque la durée des données de la "source fiable" est finie, elle fixe une limite supérieure à l'intervalle de temps pendant lequel nous pouvons espérer que les processus cyclostationnaires passés saisis dans notre caractérisation soient représentés dans les séries temporelles futures.

Mais il y a un point plus important à renforcer ici et je pense que nous sommes tous d'accord sur le fait que, indépendamment de la "précision historique" des données ou de la durée représentée par les données, la valeur de l'utilisation des données historiques et du backtesting pour "optimiser" une stratégie commerciale dépend entièrement de la personne assise derrière le clavier qui connaît les questions auxquelles le backtesting doit répondre. La quantité ne prime pas sur la qualité, ni la longueur des données historiques, ni les heures passées à faire passer une optimisation par des backtests itératifs ne répondront aux questions auxquelles il faut répondre si la question n'a pas été bien définie au départ. Combien de temps vous a-t-il fallu pour réaliser que "quels paramètres me donneront le maximum de profits ou le minimum de drawdown ?" n'était PAS la question à laquelle il fallait essayer de répondre par le backtesting :)

Schnappi, cela dépend de votre objectif en termes de ce que vous essayez d'obtenir. Voulez-vous un ensemble de données qui reflète d'autant mieux les nuances de prix historiquement exactes ou êtes-vous intéressé par le nombre de séries temporelles sur lesquelles vos déclencheurs de transaction et votre gestion financière sont testés ? Il n'y a pas de mauvaise réponse, chacun aborde le trading de marché différemment bien sûr. Personnellement, je n'utilise pas les données historiques pour tester les séries chronologiques linéaires. Je sais que je ne suis pas le seul à le faire, mais je reconnais volontiers que la majorité des gens ne le font pas. J'utilise les données historiques pour extraire la nature statistique brute qui sous-tend les caractéristiques d'une paire de devises (décomposition de Lévy-Itō) que j'utilise ensuite pour créer des séries chronologiques statistiquement équivalentes mais non identiques de données historiques par le biais de routines Monte Carlo. Puis je fais des backtests avec ces séries historiques fabriquées.(Ce n'est pas une lecture légère mais j'ai inclus le lien au cas où vous ne seriez pas déjà au courant et que vous voudriez vous documenter).

Tout comme les prévisions météorologiques, vous ne prévoyez pas le temps de demain en vous concentrant sur la connaissance des aspects météorologiques d'aujourd'hui et d'hier à des degrés de précision et d'exactitude toujours plus élevés, mais vous créez plutôt des modèles qui capturent les statistiques inhérentes à l'évolution des paramètres météorologiques (température, humidité, pression, etc.), puis vous modifiez intentionnellement les conditions initiales et laissez le monte carlo avancer dans le temps, vous faites cela quelques milliers de fois et vous faites la moyenne des résultats (dans l'esprit, les détails réels sont plus compliqués naturellement) et cela constitue la base des prévisions de demain "des minima au milieu des années 30 et des maxima dans la partie supérieure des années 60".

Si vous abordez l'idée de filtrer les mauvais ticks des données historiques plus anciennes parce que vous voulez simplement backtester 10 ans de données au lieu de 3 ans, alors je vous préviens que vous risquez de tomber dans le piège de la "quantité au détriment de la qualité" auquel beaucoup de backtesters succombent à un moment donné de leur carrière. J'ai été dans cette situation une fois, et j'y suis resté pendant un certain temps. J'étais convaincu que mes codes perdants pourraient devenir gagnants si seulement je disposais de données historiques plus longues pour optimiser le backtest. Peut-être que c'est vrai pour certains et que le fait d'avoir un backtest plus long leur permet de réaliser des bénéfices sur le forward-testing, mais pour moi, cela s'est avéré être de l'or en barre (et beaucoup de temps perdu).

Si vous voulez des enregistrements historiques plus longs parce que vous utilisez des fonctions d'autocorrélation et autres, alors vous devriez probablement créer vos propres séries de données de prix virtuelles/synthétiques pour affiner vos verrouillages et vos verrouillages de phase, car vous pouvez alors contrôler directement la robustesse des protocoles de verrouillage par le biais de la façon dont vous fabriquez les séries temporelles en premier lieu.

Je ne prétends pas avoir les bonnes réponses, je dis simplement que si nous ne commençons pas par nous poser les bonnes questions, nous ne pouvons pas espérer que les réponses soient d'une quelconque utilité pour notre objectif global (les profits, vraisemblablement).

 
Oui, je connais ces termes, mais surtout à un niveau théorique. En fait, j'ai une formation en ingénierie matérielle et je ne m'occupe d'algorithmes statistiques que depuis un peu plus d'un an maintenant. Mes projets actuels sont menés en collaboration avec deux mathématiciens, et la plupart des travaux théoriques sont donc réalisés par eux. Je suis sûr qu'ils seraient plus à même de discuter de ces sujets avec vous :). Mais c'est un sujet fascinant. Je me souviens que le sujet de l'histoire inventée a été abordé il y a quelques mois, mais nous ne l'avons jamais abordé. Je teste toujours la "vraie" histoire... (d'une source "fiable").
 
Phillip : Tout d'abord, merci beaucoup pour ces informations.
Vous dites que vous extrayez les caractéristiques statistiques d'un marché, puis créez des données de marché synthétisées et effectuez des simulations Monte-Carlo sur ces données. C'est extrêmement intéressant, mais malheureusement, cela dépasse mes compétences. J'ai commencé à lire les deux liens que vous avez postés mais je dois dire que je ne suis pas en mesure de les comprendre. J'ai une formation universitaire, mais pas en mathématiques ou quelque chose de similaire. Mon approche est un peu plus, disons, "pratique" - du moins du point de vue d'un trader discrétionnaire. C'est vraiment triste. Vous ne proposez probablement pas de stages, n'est-ce pas ?

Je suis conscient de ce que vous avez appelé "la quantité va conduire à l'erreur de qualité" - puisque j'ai déjà perdu beaucoup de temps à être bloqué à ce point. Bien que je ne dirais pas que j'aurais perdu ce temps, mais c'est un point différent. Non, la raison pour laquelle je suis entré dans cette discussion est qu'en ce moment, je suis en train d'améliorer mon processus de développement lui-même. Je vais acquérir des données supplémentaires pour augmenter mon champ d'action. Nous travaillons également sur une solution pour automatiser les backtests avec MT, etc.
 

schnappi Je viens juste de voir votre message, je peux apprécier le sentiment et je suis d'accord qu'au premier abord, tout semble plutôt complexe (pour être sûr, ce n'est pas simple) mais ne vous laissez jamais aller à penser que ce n'est pas quelque chose que vous ne pouvez pas maîtriser par vos propres moyens un jour dans un avenir proche. Il n'est pas nécessaire d'être titulaire d'un diplôme universitaire pour comprendre et utiliser ce matériel, il suffit d'avoir le temps, l'engagement et la volonté de s'y consacrer et vous finirez inévitablement par maîtriser les sujets.

Il est utile d'être sensibilisé à certains des termes et des sujets qui existent dans le secteur de la finance d'investissement professionnelle existante, ce qui contribuera à raccourcir la courbe d'apprentissage, et j'espère que mes articles vous ont aidé à cet égard. Je ne serais pas là où j'en suis aujourd'hui si d'autres avant moi ne m'avaient pas offert leurs épaules pour que je puisse m'y tenir.

Nous, les traders quantitatifs "maison", avons tous beaucoup en commun, nos origines sont extrêmement diverses et peu d'entre nous ont fait des études supérieures en finance ou en programmation, mais ce qui nous manque dans l'éducation formelle, nous voulons le compenser par la ténacité et l'ambition. Cela a fonctionné pour Thomas Edison... il est vrai que ce n'est pas le meilleur exemple du point de vue de l'éthique et de la morale, mais son prototype de 10 000 ampoules est la morale de l'histoire.

Vous finirez par reconnaître, et peut-être l'avez-vous déjà fait, que votre rythme de progression personnel est itératif par nature. Vous en apprenez davantage sur les techniques de codage et vos codes deviennent plus sophistiqués, vous en apprenez davantage sur les stratégies commerciales qui ont ou n'ont pas fonctionné dans le passé et vous affinez un peu plus vos propres stratégies, vous en apprenez davantage sur la gestion du risque par rapport à la mesure du risque et vous commencez à vous attaquer à votre risque de ruine d'une manière dont vous n'aviez même pas conscience d'avoir besoin au départ.

Et ce n'est pas parce que mon approche est apparemment complexe que cette complexité est une nécessité... des approches beaucoup plus simples et beaucoup moins complexes peuvent être supérieures à tous points de vue... je ne suis simplement pas assez intelligent pour avoir compris comment le faire. Il existe de nombreuses façons follement complexes de fabriquer une ampoule, et des méthodes plus complexes ne garantissent pas une meilleure ampoule.

Ne vous laissez donc pas décourager par les perceptions que vous pourriez avoir entre la complexité/simplicité de votre approche et l'absence de celle-ci dans la mienne... vous pouvez très bien être sur la bonne voie alors que je suis à côté de la plaque.

 

1005phillip: 2010.03.17 18:38

Voici(script mq4 ci-joint) ce que j'utilise pour faire le travail, il n'est pas joli (le code qui est) et pourrait faire l'objet d'un peu de nettoyage et de changement des si répétitifs pour les interrupteurs, etc.

Note : Les heures d'ouverture des bougies W1 sont automatiquement alignées sur le premier jour de la semaine de négociation (lundi) et les heures d'ouverture des bougies MN sont automatiquement alignées sur le premier jour de marché ouvert du nouveau mois.
Ce script est cassé. Le premier jour de la semaine de négociation est le dimanche (2200z) et non le lundi. Et il ne gère pas les jours fériés du vendredi ou du lundi. Correction simple :
      time0=Time[i];
//    if((TimeDayOfWeek(time0)==1 && TimeDayOfWeek(Time[i+1])==5) || i==0)
      if (TimeDayOfWeek(time0) < TimeDayOfWeek(Time[i+1])         || i==0)