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
Apparemment, les développeurs ont juste besoin de clouer le site web en grosses lettres dans un endroit visible : "Il n'y a pas de tiques et il n'y en aura pas ! Les discussions sur les ticks ainsi que sur les courtiers seront supprimées des forums" :o)))). Sinon, tout va tourner en rond chaque semaine. Juste les mots des malades sans aucune preuve détaillée de la nécessité de garder les tiques...
Il serait intéressant de voir l'historique des tics des comptes réels.
La littérature est tellement passionnée par les graphiques qu'il faut y réfléchir à deux fois avant d'utiliser un EA pour le trading réel.
Et je n'ai vu nulle part que le courtier a mis en place les archives des ticks réels - alors je commence à penser, peut-être qu'il y a vraiment quelque chose à cacher ?
Je soutiens que la marge d'erreur dans la modélisation des minutes est de 1 à 2 points. Et cette erreur est parfaitement acceptable et normale.
Renat,
Je ne le prouverai pas car je suis absolument d'accord avec vous. De plus, je ne vais pas épingler qui que ce soit au mur. Je déclare : Je suis assez satisfait de la modélisation des tics dans le testeur. Je n'ai absolument aucun reproche à lui faire.
En même temps, je le répète une fois de plus :
La nécessité d'une histoire de tique n'a rien à voir avec la modélisation dans le testeur.
Et tout ce que je pourrais dire pour justifier sa nécessité, je l'ai dit plus haut.
solandr,
Si les utilisateurs ne sont pas proactifs et persévérants pour expliquer leurs besoins aux développeurs, tant les utilisateurs que les développeurs en pâtiront.
Si les développeurs ne font pas preuve de patience, de compréhension, mais aussi d'une approche stratégique lors du développement de leurs produits, tant les utilisateurs que les développeurs en pâtiront.
J'espère que vous comprenez cela.
Sera-t-il compatible avec MQL4, ou s'agira-t-il d'une nouvelle version ?
...Sera-t-il compatible avec MQL4 ou s'agira-t-il d'une nouveauté ?
Vous ne cessez de parler de l'aspect PRIX du marché. Ici, vous avez sans doute réussi et l'erreur dans la modélisation du PRIX est insignifiante.
Cependant, le flux de cotations a d'autres paramètres qui sont TOTALEMENT détruits par la modélisation, surtout pendant les périodes de mouvements de nouvelles.
À mon avis, vous avez besoin UNIQUEMENT de l'historique des ticks à partir duquel vous pouvez obtenir TOUTES les échéances et pas seulement les échéances, mais aussi les tickframes (dans une bougie, par exemple, 10 ticks) et les graphiques cagi et les croisements et les zéros.
C'est-à-dire que TOUTES les restrictions artificielles liées aux délais sont supprimées.
Absolument d'accord avec cela. Les développeurs doivent-ils vraiment prouver que les trames de tic-tac ont le même droit d'exister que les trames de temps ? S'il est difficile de stocker UNIQUEMENT l'historique des ticks en raison d'une grande quantité de données pour une période significative, vous pouvez au moins stocker des ticks fixes, comme c'est le cas actuellement pour les périodes. C'est mon souhait et cela n'a rien à voir avec les testeurs, les conseillers experts et autres bêtises. Je négocie sur un compte réel depuis environ un an et je ne le fais que manuellement. S'il y a une sorte de mouvement de prix, il est élémentaire de négocier avec profit, mais si le prix ne fait que dériver d'avant en arrière au même endroit, aucun conseiller expert ne sera utile. Et laisser l'ordinateur prendre la décision par lui-même - Dieu nous en préserve.
Je pense donc que les échelles en tic-tac sont un reflet beaucoup plus précis de l'évolution des prix, et je me sentirais personnellement plus à l'aise avec elles. Comment cela peut-il être difficile ?
Vous pouvez construire n'importe quel cadre à partir d'eux (même les délais, même les X et les Y, même
à enrouler selon d'autres critères).
Ce qui est vraiment important, c'est la régularité de l'axe des graphiques principaux de MT4,
qui sont basés sur des données collectées à intervalles de temps constants...
Mais cela peut être décidé
seulement dans la prochaine version de MT ... Alors vous pouvez voir l'image au moins une fois
dans les vagues (je n'écris pas Eliot, parce qu'il ya des vagues, mais leur structure est très discutable ...).
En général, je suis en faveur d'une histoire de base de minutes de QUALITÉ.
En tout cas, si l'on fait une simple estimation sur ceux qui se sont exprimés dans cette branche, il y a une majorité absolue de ceux qui le voudraient.
Sur le serveur, je ne stocke que les ticks, et je n'autorise que leur téléchargement.
Sur le client, je créerais toutes les TimeFrames (et TickFrames) nécessaires à partir de ticks.
Ainsi, pour obtenir un graphique de n'importe quel TF pendant un an, il faudrait 35,7 Mb de trafic (calculs de Yurixx).
Maintenant, MT4 aura besoin d'environ 20,763 Mo d'historique pour toutes les TF pour la même période (15,71 + 3,142 + 1,047 + 0,524 + 0,262 + 0,065 + 0,011 + 0,002).
En résumé, les avantages de l'histoire de la tique:
- L'utilisateur décide lui-même des TF qu'il souhaite et peut toujours les construire lui-même.
Contre l'histoire de la tique :
- la quantité de trafic consommé augmente de 1,7 fois (par rapport au téléchargement de toutes les TF) ;
- elle augmente la charge du processeur (pour la construction constante des TF nécessaires).
Si je fabriquais mon propre terminal, je réfléchirais bien d'abord.....