Le testeur fonctionne-t-il correctement ? - page 5

 
Integer:
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.
 
Renat:
Integer:
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.
Cela se produit dans n'importe quelle donnée d'une minute de temps - voyez par vous-même et dans ces citations, que j'ai téléchargées d'Alpari, je pense, aussi.



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.
 
VladislavVG:
Renat:
Entier:
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.
Cela se produit dans n'importe quelle minute de données, vous pouvez le voir par vous-même et dans ces citations que j'ai téléchargées d'Alpari aussi.

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.
 
Renat:
VladislavVG:
Renat:
Entier:
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.
Si vous n'avez pas une telle idée, vous pouvez utiliser la main droite pour régler le problème.

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.
Oui, j'ai déjà vu et corrigé le message précédent.

Bonne chance. Salutations, Vladislav.
 
VladislavVG:

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.
 
Renat:
VladislavVG:

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.
Est-ce que je comprends bien que le testeur doit déformer fortement les tests dans une telle situation ? Peut-être devrions-nous ajouter une telle vérification au script standard ? Il est clair qu'il est préférable d'utiliser des données vérifiées pour les tests. Mais de nombreux traders testent les systèmes sur les données de leur courtier - des malentendus sont possibles.

Bonne chance. Salutations, Vladislav.
 
VladislavVG:

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.
Est-ce que je comprends bien que le testeur doit déformer fortement les tests dans une telle situation ? Peut-être devrions-nous ajouter une telle vérification au script standard ? Il est clair qu'il est préférable d'utiliser des données vérifiées pour les tests. Mais de nombreux traders testent les systèmes sur les données de leur courtier - des malentendus sont possibles.

Bonne chance. Sincèrement, Vladislav.
Absolument faux. Il n'y a pas de distorsion, à l'exception d'une réflexion erronée sur un pip dans la tête des traders.

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.
 
Renat:
VladislavVG:

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.
Est-ce que je comprends bien que le testeur doit déformer fortement les tests dans cette situation ? Peut-être devrions-nous ajouter une telle vérification au script standard ? Bien sûr, il est préférable d'utiliser des données vérifiées pour les tests. Mais de nombreux traders testent les systèmes sur les données de leur courtier - des malentendus sont possibles.

Bonne chance. Salutations, Vladislav.
Absolument faux. Il n'y a pas de distorsion autre que des pensées erronées sur un seul pip dans la tête des traders.

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 n'ai jamais vraiment espéré une exécution précise. Et concernant les tiques, je les comprends très bien. En général, tous mes stops sont en dehors des zones de retournement statistiquement significatives et certainement pas plus près que 2,5 ATR derrière l'extremum de la barre précédente :). C'est-à-dire qu'il n'y a pas la moindre trace d'algorithmes de "scalping". En ce qui concerne le demi-écart, je dirais même qu'une valeur exprimée en TAP est une estimation plus précise (vérifiée par la pratique).

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.
 
Renat писал (а):

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.
 
Integer:
Renat a écrit :

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.
Ils ont donc été importés dans le serveur commercial - ceci est courant pour les données historiques des périodes précédentes.