Le testeur fonctionne-t-il correctement ? - page 5
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
Ouais... J'ai pris de l'avance sur ce coup-là. Il s'avère qu'il existe des barres dont le prix d'ouverture est égal au prix de clôture de la barre précédente. Je ne sais pas quel système MT utilise pour dessiner les barres. Je pense que seuls les développeurs seront en mesure de l'expliquer. J'aimerais beaucoup le comprendre.
S'il y a eu une période de hors quota, alors lors de l'apparition des cotations, le courtier peut donner un tick avec le même prix. Mais ce n'est qu'une supposition.
Si seules nos données en temps réel sont utilisées et qu'il n'y a pas d'interruption entre les sessions ou de redémarrage du serveur, la clôture d'une barre ne peut pas être égale à l'ouverture de la barre suivante. Si des données importées sont utilisées, elles peuvent l'être.
Ouais... J'étais pressé.... Il s'avère qu'il existe des barres dont le prix d'ouverture est égal au prix de clôture de la barre précédente. Je ne suis pas sûr de l'exactitude de l'équation. Je pense que seuls les développeurs seront en mesure de l'expliquer. J'aimerais beaucoup le comprendre.
S'il y a eu une période de hors quota, alors lors de l'apparition des cotations, le courtier peut donner un tick avec le même prix. Mais ce n'est qu'une supposition.
Si seules nos données en temps réel sont utilisées et qu'il n'y a pas d'interruption entre les sessions ou de redémarrage du serveur, la clôture d'une barre ne peut pas être égale à l'ouverture de la barre suivante. Si des données importées sont utilisées, cela peut arriver.
Voici un exemple : les cotations en temps réel, votre démoteur. Regardez la barre en surbrillance et les deux barres au-dessus. Sur la barre en surbrillance, la valeur du volume en tick doit être de 0. Puisque le changement de prix à ce niveau est pris en compte par le volume du tick de la barre précédente.
Deux barres plus haut que 1 est correct.
Et ce n'est pas un cas isolé. Regardez l'histoire. Je pense que ce n'est pas à cause des requêtes.
C'est pourquoi la question est apparue.
Bonne chance. Sincèrement, Vladislav.
ZS Désolé - cet exemple n'est pas correct - j'ai regardé au mauvais endroit. Je vais maintenant le chercher ailleurs.
ZZZY exécuté votre script de données - les yeux avaient peur de faire une erreur à nouveau - dans ceux que j'ai reçu le temps réel de votre serveur est vraiment pas. Je retire donc la question.
Bonne chance. Salutations, Vladislav.
Ouais... J'ai sauté sur l'occasion avec ce one..... Il s'avère qu'il existe des barres dont le prix d'ouverture est égal au prix de clôture de la barre précédente. Je ne sais pas quel système MT utilise pour dessiner les barres. Je pense que seuls les développeurs seront en mesure de l'expliquer.
S'il y a eu une période de hors quota, alors lors de l'apparition des cotations, le courtier peut donner un tick avec le même prix. Mais ce n'est qu'une supposition.
Si seules nos données rltime sont utilisées et qu'il n'y a pas d'écarts entre les sessions ou de redémarrage du serveur, la clôture d'une barre ne peut pas être égale à l'ouverture de la suivante. Si des données importées sont utilisées, elles peuvent l'être.
Voici un exemple : les cotations en temps réel, votre démoteur. Regardez la barre en surbrillance et les deux barres au-dessus. Sur la barre en surbrillance, la valeur du volume en tick doit être de 0. Puisque le changement de prix à ce niveau est pris en compte par le volume du tick de la barre précédente.
Deux barres plus haut que 1 est correct.
Et ce n'est pas un cas isolé - il est toujours présent. Donc, pour être plus correct, je n'ai pas trouvé une seule barre qui contiendrait zéro dans le cas sélectionné. Regardez l'histoire. Je pense qu'il ne s'agit pas de requêtes.
C'est pourquoi la question s'est posée.
Bonne chance. Sincèrement, Vladislav.
Et que vouliez-vous montrer avec cet exemple ? L'esquive des barres à partir d'une cotation (OHLC = un prix) ?
Il s'agit donc d'une situation tout à fait normale. Il n'y a pas d'erreurs ou de divergences.
Ouais... J'ai sauté sur l'occasion avec ce one..... Il s'avère qu'il existe des barres dont le prix d'ouverture est égal au prix de clôture de la barre précédente. Je ne sais pas quel système MT utilise pour dessiner les barres. Je pense que seuls les développeurs seront en mesure de l'expliquer.
S'il y a eu une période de hors quota, alors lors de l'apparition des cotations, le courtier peut donner un tick avec le même prix. Mais ce n'est qu'une supposition.
Si seules nos données rltime sont utilisées et qu'il n'y a pas d'écarts entre les sessions ou de redémarrage du serveur, la clôture d'une barre ne peut pas être égale à l'ouverture de la suivante. Si des données importées sont utilisées, elles peuvent l'être.
Voici un exemple : des cotations en temps réel sur votre démoserveur. Regardez la barre en surbrillance et les deux barres au-dessus. Sur la barre en surbrillance, la valeur du volume en tick doit être de 0. Puisque le changement de prix à ce niveau est pris en compte par le volume du tick de la barre précédente.
Deux barres plus haut que 1 est correct.
Et ce n'est pas un cas isolé - il est toujours présent. Donc, pour être plus correct, je n'ai pas trouvé une seule barre qui contiendrait zéro dans le cas sélectionné. Regardez l'histoire. Je pense qu'il ne s'agit pas de requêtes.
C'est pourquoi la question s'est posée.
Bonne chance. Sincèrement, Vladislav.
Et que vouliez-vous montrer avec cet exemple ? L'esquive des barres à partir d'une cotation (OHLC = un prix) ?
C'est donc une situation tout à fait normale. Il n'y a pas d'erreurs ou de divergences.
Bonne chance. Salutations, Vladislav.
Désolé - cet exemple est faux - j'ai regardé au mauvais endroit. Je vais chercher ailleurs.
ZZZY a exécuté votre script de données - les yeux avaient peur de faire une erreur à nouveau - dans ceux que j'ai reçu le temps réel de votre serveur vraiment pas une telle chose. Je retire donc la question.
Oui, j'ai également écrit un script pour vérifier la condition if(Close[previous]==Open[current]) et j'ai trouvé cela uniquement sur les données importées. Il n'y a rien de tel sur nos données de temps libre.
Désolé - cet exemple est faux - j'ai regardé au mauvais endroit. Je vais chercher ailleurs.
ZZZY a exécuté le script de vos données - les yeux avaient peur de faire une erreur à nouveau - dans ceux que j'ai reçu le temps réel de votre serveur vraiment pas une telle chose. Donc la question a été supprimée.
Oui, j'ai aussi écrit un script pour vérifier la condition if(Close[previous]==Open[current]) et je l'ai trouvé seulement sur les données importées. Il n'y a rien de tel sur nos données de temps libre.
Bonne chance. Salutations, Vladislav.
Oui, j'ai également écrit un script pour vérifier la condition if(Close[previous]==Open[current]) et j'ai trouvé cela uniquement sur les données importées. Il n'y a rien de tel sur nos données de relais.
Bonne chance. Sincèrement, Vladislav.
Comprenez que vous ne devez jamais vous fier aux tiques dans les tests. Au contraire, vous devez ignorer les mouvements du bruit à l'intérieur du demi-étalage. Presque tous les traders passent par des pips insignifiants en espérant un pip supplémentaire. Et la plupart des traders se justifient en disant "non, je ne suis pas un trader de pip, je veux une exécution précise" :)
Les gens se trompent en espérant une exécution absolument précise et garantie, et sont ensuite surpris de voir qu'en réalité ils obtiennent des requêtes, et qu'il est impossible de conclure une transaction dans un marché rapide. De plus, beaucoup d'entre eux ne traitent pas du tout les requêtes et autres réponses du serveur commercial.
Oui, j'ai également écrit un script pour vérifier la condition if(Close[previous]==Open[current]) et j'ai trouvé cela uniquement sur les données importées. Il n'y a rien de tel sur nos données de relais.
Bonne chance. Salutations, Vladislav.
Comprenez que vous ne devez jamais vous fier aux tiques dans les tests. Au contraire, vous devez ignorer les mouvements de bruit à l'intérieur du demi-étalage. Presque tous les traders passent par des pips insignifiants en espérant un pip supplémentaire. Et la plupart des traders se justifient en disant "non, je ne suis pas un trader de pip, je veux une exécution précise" :)
Les gens se trompent en espérant une exécution absolument précise et garantie, et sont ensuite surpris de voir qu'en réalité ils obtiennent des requêtes, et qu'il est impossible de conclure une transaction dans un marché rapide. De plus, beaucoup d'entre eux ne traitent pas du tout les requêtes et autres réponses du serveur commercial.
Je voulais savoir dans quelle mesure ces "interférences" (appelons-les ainsi) peuvent affecter la qualité du testeur lui-même. J'ai écrit plus haut que je ne considère pas la stratégie elle-même.
De votre réponse, je conclus qu'ils ne le peuvent pas. C'est bien pour toi.
Bonne chance. Salutations, Vladislav.
Si seules nos données de relais sont utilisées et qu'il n'y a pas d'écarts entre les sessions ou de redémarrage du serveur, la clôture d'une barre ne peut pas être égale à l'ouverture de la suivante. Si des données importées sont utilisées, elles peuvent l'être.
Je n'ai pas de données importées, mais des données téléchargées vers MT "légalement" depuis le DC.
Si seules nos données de relais sont utilisées et qu'il n'y a pas d'écarts entre les sessions ou de redémarrage du serveur, alors la clôture d'une barre ne peut pas être égale à l'ouverture de la suivante. Si des données importées sont utilisées, cela peut se produire.
Je n'ai pas de données importées, mais j'ai téléchargé sur MT "légalement" depuis DC.