L'indicateur se corrompt - page 2

 
jjc:

Par exemple, s'il est actuellement 8 heures du matin, tout ce qui, dans le code, suppose que (a) la barre de 7 heures du matin date d'il y a 60 barres, ou même (b) qu'une barre de 7 heures du matin existe.

Bon point, je n'avais pas apprécié le fait que les graphiques étaient M1 lorsque je les ai regardés pour la première fois... il est assez fréquent que les barres M1 soient manquantes dans les périodes calmes, la nuit par exemple.
 
RaptorUK:
Bon point, je n'avais pas apprécié le fait que les graphiques étaient M1 quand je les ai regardés pour la première fois... il est assez fréquent que les barres M1 manquent aux moments calmes, la nuit par exemple.
Dans ce cas, je pense qu'il est plus probable qu'il s'agisse d'une perte temporaire de connexion avec le courtier, mais le principe et les implications sont les mêmes.
 
jjc:
Dans ce cas, je pense qu'il est plus probable qu'il s'agisse d'une perte temporaire de connexion au courtier, mais le principe et les implications sont les mêmes.
...On peut également remarquer sur la capture d'écran "Move Error" que les lignes violettes cessent d'être tracées au moment où il semble qu'il manque une barre M1.
 
AnkaSoftware:

Hmm, "les nouvelles données historiques sont ajoutées au graphique", comment ? L'indicateur est lancé et n'est pas modifié. Nous avons un lookback fixe de 1000 barres.

L'

indicateur ne charge pas de données historiques.

Quelqu'un de l'équipe de développement peut-il y jeter un coup d'oeil ?

Vous avez dit... "J'ai développé un indicateur qui fonctionne bien pendant les 16 premières heures environ"... 16 heures x 60 minutes = 960 barres ... que se passe-t-il si vous réduisez votre lookback à 500 barres, avez-vous des problèmes après 8 heures ?
 

Jic, Merci pour les observations.

Les tests sont effectués sur un serveur VPS du RNC avec une connexion fiable et les comptes de démonstration utilisés pour les tests sont avec les courtiers IBFX et VantageFX.

Je fais un RefreshRates() à chaque tick et j'utilise les fonctions normales de timeseries pour accéder aux données des barres. Le code utilisé pour mettre à jour les indicateurs est donné dans mon post précédent voir la fonction DrawMoveEx. Je pense que la TimeSeries n'a pas de barres manquantes de 0 à 'Bars -1'. Faites-moi savoir si cette hypothèse est incorrecte.

Un autre instantané ci-joint, avec une échelle de temps correcte, et sans défilement vers la droite (avec les données IBFX actuelles).

Avez-vous eu l'occasion de regarder le fichier Excel joint au message 2011.10.07 15:30

 

AnkaSoftware:
I believe the TimeSeries does not have missing bars from 0 to 'Bars -1'. Let me know if this assumption is incorrect.

Cette hypothèse semble certainement incorrecte car votre capture d'écran originale "Move Error" comporte 16 barres entre chaque marqueur de l'axe X - vous pouvez les compter vous-même - mais l'une des périodes couvre 21 et non 16 minutes. Et, comme RaptorUK le dit, ce n'est pas une hypothèse que vous pouvez faire sans risque dans votre code. Il n'y aura pas nécessairement une transaction chaque minute de la journée - bien que je serais surpris qu'il n'y en ait pas sur la paire GBPUSD en dehors des jours fériés - et donc il n'y aura pas nécessairement une barre M1 pour chaque minute.

Si vous croyez qu'il n'y a pas de barres manquantes - alors qu'il est évident qu'il y a des barres manquantes dans l'une de vos captures d'écran - alors vous codez probablement sur la base de cette hypothèse/croyance. Je ne considérerais pas votre dernière capture d'écran comme une contre-preuve, car il pourrait y avoir (a) des données manquantes avant la période indiquée sur la capture d'écran qui (b) affectent d'une manière ou d'une autre les calculs pour les barres qui sont indiquées sur la capture d'écran.

La chose la plus suspecte est que les lignes violettes s'arrêtent dans la capture d'écran originale pendant la période où il y a clairement une barre manquante. Je ne pourrais pas commenter davantage, ou faire une analyse de vos feuilles de calcul, sans voir le code complet.

 
AnkaSoftware:

Jic, Merci pour les observations.

Les tests sont effectués sur un serveur VPS du RNC avec une connexion fiable et les comptes de démonstration utilisés pour les tests sont avec les courtiers IBFX et VantageFX.

Je fais un RefreshRates() à chaque tick et j'utilise les fonctions normales de timeseries pour accéder aux données des barres.

Ce n'est probablement pas la cause de votre problème, mais... RefreshRates() ne fait aucune différence si vous utilisez ces fonctions : https://docs.mql4.com/series RefreshRates rafraîchit uniquement ces variables : https://docs.mql4.com/predefined/variables
 
jjc:

Cette hypothèse semble certainement incorrecte car votre capture d'écran originale "Move Error" comporte 16 barres entre chaque marqueur de l'axe X - vous pouvez les compter vous-même - mais l'une des périodes couvre 21 et non 16 minutes. Et, comme RaptorUK le dit, ce n'est pas une hypothèse que vous pouvez faire sans risque dans votre code. Il n'y aura pas nécessairement une transaction chaque minute de la journée - bien que je serais surpris qu'il n'y en ait pas sur la paire GBPUSD en dehors des jours fériés - et donc il n'y aura pas nécessairement une barre M1 pour chaque minute.

Si vous croyez qu'il n'y a pas de barres manquantes - alors qu'il est évident qu'il y a des barres manquantes dans l'une de vos captures d'écran - alors vous codez probablement sur la base de cette hypothèse/croyance. Je ne considérerais pas votre dernière capture d'écran comme une contre-preuve, car il pourrait y avoir (a) des données manquantes avant la période indiquée sur la capture d'écran qui (b) affectent d'une manière ou d'une autre les calculs pour les barres qui sont indiquées sur la capture d'écran.

La chose la plus suspecte est que les lignes violettes s'arrêtent dans la capture d'écran originale pendant la période où il y a clairement une barre manquante. Je ne pourrais pas commenter davantage, ou faire une analyse de vos feuilles de calcul, sans voir le code complet.

Raptor, je vais vérifier "que se passe-t-il si vous réduisez votre lookback à 500 barres, avez-vous des problèmes après 8 heures ?" et je vous renverrai la réponse.

JIC, veuillez noter que le problème ne se produit pas sur les plateformes 32 bits. J'ai fourni un code dans l'un des messages précédents.

 
AnkaSoftware:
Je crois que la TimeSeries n'a pas de barres manquantes de 0 à 'Bars -1'. Faites-moi savoir si cette hypothèse est incorrecte.

Bien sûr que non, il y a des barres numérotées de 0 à Bars-1. ArraySize(Close) == Bars toujours.

Cependant, il y a toujours des barres sautées. Du vendredi 21:59z, la prochaine barre est le dimanche 22:00z. Les week-ends et les jours fériés et les minutes sans activité.

Vous ne pouvez pas supposer que Time[x] == Time[x+1] + 60*Period() il ne sera pas sur une barre sautée.

Si vous voulez de l'aide avec VOTRE indicateur, postez VOTRE code - pas de lecteurs de pensées ici.

 
AnkaSoftware:

Quelques informations supplémentaires

a) La corruption des indicateurs ne se produit que sur la plateforme Windows 64 bit.

b) J'ai fait un dump du tableau des indicateurs avant et après la corruption - les mêmes sont disponibles dans le fichier xls ci-joint avec des commentaires.

Jetez un œil aux valeurs de temps Unix dans votre feuille de calcul, les écarts entre chaque valeur adjacente devraient être de 60, 60 secondes, il y a quelques écarts de 240 secondes et au moins un écart de 120 secondes. Votre code est-il conçu pour gérer les barres M1 manquantes ?
Raison: