J'ai besoin d'un bon fichier historique pour EURUSd - page 3
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
je pense qu'aucun type de données que vous pouvez obtenir pour moins de quelques milliers de $ n'est bon pour m1 (ou plus petit !)...
probablement que metatrader ne convient pas du tout pour cela...
Na... Voir la liste que Phillip a donnée. Il y a d'excellentes sources gratuites... Elles sont juste difficiles à convertir dans un format utilisable.
Avez-vous mesuré leur qualité ?
Je pense qu'il y a une raison pour laquelle certains fournisseurs de données vendent leurs données pour plusieurs centaines de dollars (par marché).
Comment savez-vous qu'ils sont excellents ?
Avez-vous mesuré leur qualité ?
Je pense qu'il y a une raison pour laquelle certains fournisseurs de données vendent leurs données pour plusieurs centaines de dollars (par marché).
Oui. C'est plus pratique. C'est tout.
Ma question n'était pas ironique : avez-vous mesuré la qualité de manière objective ?
Allez sur le site de Dukascopy. Ils l'ont au tick. Avec une précision de l'ordre de la milliseconde (oui - les timestamps ont .xxx à la fin). Leur réputation et le fait qu'ils sont l'un des plus grands ECN du monde sont suffisants. Mais lorsque vous essayerez de télécharger leurs données, vous comprendrez de quoi je parle..... C'est une douleur incroyable dans le cul.
même les données tick ne sont pas une garantie qu'elles ne contiennent pas d'écarts ou de pics. même si vous agrégez leurs données tick à m1 pour les rendre compatibles avec mt, cela ne garantit pas une haute qualité.
et btw : concernant la réputation de dukascopy il y a des avis mitigés... mais afaik les discussions concernant les brokers sont interdites ici.
donc je suppose que vous n'avez pas encore fait une analyse de ce genre. de toute façon : merci pour le chat, je dois partir maintenant... bons trades.
(...) même les données en tick ne sont pas une garantie qu'elles ne contiennent pas de gaps ou de pics.
Les écarts et les pics sont normaux. Si vous voulez des données sans eux, alors par définition vous voulez une source moyenne - des données indicatives. Vous oubliez que vous finirez par négocier avec un vrai courtier ; les vrais courtiers ont des écarts et des pics. Ils en ont tous.
Quant à l'"analyse", je ne sais pas vraiment ce que vous entendez par là. Quel genre d'analyse faites-vous ?
Phillip : veuillez consulter ma question de la page 1, concernant les données historiques de disktrading :
Les données de disktrading sont des données indicatives, ce qui signifie (comme Gordon l'a expliqué) que les données (prix) représentent la valeur moyenne de plusieurs flux de prix à ce moment-là. Il ne s'agit pas du flux de prix spécifique d'un courtier en forex spécifique donné (c'est-à-dire un teneur de marché dans cette activité de forex hors bourse).
Gordon: Je pense que schnappi et moi sommes en train de créer une confusion avec les termes/phrases "gaps et spikes"...Je crois que vous utilisez ces termes pour caractériser les pics momentanés (gros ordres placés dans des conditions de marché moins liquides) et les bougies manquantes attendues (pas d'activité sur le marché dans la période de temps de la bougie), alors que Schnappi et moi faisons spécifiquement référence aux questions plus problématiques qui affectent certains ensembles de données historiques dans lesquels des pics de 100 pips dans une bougie donnée peuvent apparaître (d'une manière qui n'est vraiment pas caractéristique d'un instrument financier, à l'époque ou aujourd'hui) et des écarts de données s'étendant sur des jours, des semaines, et dans certains cas même des mois (encore une fois, ce n'est pas le genre d'écarts qui représente les conditions réelles du marché).
Schnappi: Oui, j'ai une série de scripts qui parcourent itérativement les ensembles de données en caractérisant et en identifiant les écarts et les pics à l'aide de la litanie standard de tests statistiques, etc. Je n'ai aucune expérience des données de trading. Pour mon style de trading sur le marché, je préfère en fait les "erreurs" contenues dans les données de disktrading comme un moyen de construire une plus grande robustesse aux déclencheurs de trades/etc.
Ma philosophie (à l'heure actuelle) est que si ma stratégie repose vraiment sur des données de prix immaculées et historiquement exactes pour faire ou défaire les ratios de profit/perte, ma stratégie est garantie d'être un échec lorsqu'elle est chargée de traiter l'espace de marché futur. À mon avis, il y a de forts corollaires à trouver avec les prévisions météorologiques (en particulier les méthodologies) et le trading quant au forex.
Gordon: Je pense que schnappi et moi créons une confusion avec les termes/phrases "gaps et spikes"...Je crois que vous utilisez ces termes pour caractériser les pics momentanés (gros ordres placés dans des conditions de marché moins liquides) et les bougies manquantes attendues (aucune activité du marché dans la période de temps de la bougie), alors que schnappi et moi faisons spécifiquement référence aux questions plus problématiques qui affectent certains ensembles de données historiques dans lesquels des pics de 100 pips dans une bougie donnée peuvent apparaître (d'une manière qui n'est vraiment pas caractéristique d'un instrument financier), à l'époque ou aujourd'hui) et des écarts de données s'étendant sur des jours, des semaines, et dans certains cas même des mois (encore une fois, ce n'est pas le genre d'écarts qui représentent les conditions réelles du marché).
Je vois. Oui, ce genre d'écarts/de pics doit être évité... Je suis d'accord.
... Pour mon style de négociation sur le marché, je préfère en fait les "erreurs" contenues dans les données de négociation sur disque comme un moyen de construire une plus grande robustesse aux déclencheurs de négociation/etc.
...
Tant que vous êtes conscient de ces limitations, il s'agit d'une façon légitime de traiter ce problème.
Pourriez-vous nous donner un peu plus de détails sur la façon dont vous définissez - disons - les mauvais ticks et les trous dans les données (au lieu des pics/écarts) ?
La façon dont je le ferais : Je pense que j'écrirais un indicateur ou un script pour les détecter. Bad tick=peut-être une barre M1 > n*ATR ou autre et un trou de données ... je ne sais pas ... en fait, il faudrait gérer les week-ends et les jours fériés (qui peuvent survenir un jour de semaine) - alors comment avez-vous fait ?