99% de qualité de modélisation mais avec une barre rouge - page 4
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
Concernant la barre rouge, êtes-vous sûr à 100% que vous copiez bien tous les fichiers hst de M1 à MN1 ?
Par exemple,
GBPUSD1.hst
GBPUSD5.hst
GBPUSD15.hst
GBPUSD30.hst
GBPUSD60.hst
GBPUSD240.hst
GBPUSD1440.hst
GBPUSD10080.hst
GBPUSD43200.hst
Oui, après avoir téléchargé les données, la première chose que j'ai faite a été d'exécuter le script pour générer tous les fichiers hst et le fichier h1 fxt.
J'ai placé tous les fichiers hst dans le dossier metatrader/history et le fichier fxt dans metatrader/tester/history.
Je pensais que le backtester n'utilisait que le fichier FXT ?
Il y a aussi une confusion sur le décalage GMT. Les données de Dukascopy sont en GMT+0. Je suppose donc que je peux effectuer un backtest avec le décalage GMT réglé sur 0, bien que mon courtier soit actuellement en GMT+2 et suive l'heure d'été ? Je suppose que les données du testeur sont complètement indépendantes du courtier, donc 17 heures sur mon courtier serait toujours 17 heures GMT+0.
Je suis moi-même confus au sujet de l'heure GMT et de l'heure des données :). Cependant, je crois que si vous utilisez les données de Dukascopy. Alors votre courtier pendant que vous effectuez un backtest devrait être enseigné comme Dukascopy. Si vos données proviennent de Forexite, alors votre courtier pendant que vous effectuez un backtest devrait être informé de Forexite. Si vous voulez placer un ordre dans le back-test @-X-Gmt, vous devez connaître le décalage horaire du courtier et savoir si et quand il s'adapte à l'heure d'été.
Ma confusion à ce sujet est la raison principale pour laquelle je n'ai pas créé de système qui repose sur le temps universel, c'est aussi l'une des raisons pour lesquelles je n'ai pas pris la peine de télécharger des données Tick.
Jetez un œil aux codes de WHRorder dans ce fil de discussion. Il donne de très bons exemples sur la façon d'utiliser les décalages dans le back-testing et les DLL pour obtenir le temps universel tout en fonctionnant en direct.
Le back-testing est une estimation de la performance du système. Je pense que vous le prenez trop au sérieux. Les recommandations habituelles pour les données tick sont pour les systèmes qui placent bien plus de 200 transactions dans les 5 ans. Il est également recommandé pour les systèmes qui ferment habituellement dans la même minute de la barre sur laquelle il a été ouvert. La plupart des systèmes qui recherchent des profits à un chiffre entrent dans cette catégorie.
Si vous pensez vraiment que votre système est un scalper digne de ce mal de tête, alors je dis qu'il sera également digne d'un test Live prolongé. Mais avec ces 200 transactions en 5 ans, je ne pense pas que ce soit le cas. Ce n'est que mon opinion, d'ailleurs.
Je pensais que le backtester utilisait uniquement le fichier FXT ?
Mon système est un scalper. Il peut conclure des transactions en quelques secondes ou minutes. D'où la nécessité de disposer de données tick précises. J'ai confirmé que le décalage GMT doit être laissé à 0 car les données sont en GMT.
Les seules choses qui me dérangent sont la barre rouge de modélisation (quelqu'un dans ce fil de discussion a déclaré que c'était parce qu'il n'y avait pas de modélisation nécessaire) et les pertes lors de l'utilisation de données historiques normales qui ne se produisent pas avec les données Dukascopy.