Erreurs, bugs, questions - page 2179
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
Essaie celle-là :
Qu'est-ce que l'iBarShift a à voir avec quoi que ce soit ?
Il s'agit d'un bug dans la fonction standard Bars.
Qu'est-ce que l'iBarShift a à voir avec quoi que ce soit ?
Il s'agit d'un bug dans la fonction standard Bars.
Cette fonction utilise également Bars(). Vous avez commencé avec l'analogue de iBarShift()
Cette fonction utilise également Bars(). Dans votre cas, tout a commencé avec l'analogue de iBarShift().
Oui, bien sûr, l'utilisation de la contrepartie iBarShift a révélé ce problème.
Si vous utilisez la fonction iBarShift que vous avez fournie, vous ne rencontrerez pas ce bogue, car un seul TF est utilisé dans cette fonction,
Et ce bug se produit lorsque vous utilisez des TF différents dans les fonctions CopyTime et Bars.
Mais Bars devrait fonctionner normalement à tout moment. Mais mon exemple montre qu'il existe un cas particulier, où iBar se bloque pendant des dizaines de secondes. Et cela n'a rien à voir avec l'histoire du chargement.
Oui, bien sûr, l'utilisation de la contrepartie iBarShift a révélé ce problème.
Si vous utilisez la fonction iBarShift que vous avez fournie, vous ne rencontrerez pas ce bogue, car un seul TF est utilisé dans cette fonction,
Et ce bug se produit lorsque vous utilisez des TF différents dans les fonctions CopyTime et Bars.
Mais Bars devrait fonctionner normalement à tout moment. Mais mon exemple montre qu'il existe un cas particulier, où iBar se bloque pendant des dizaines de secondes. Et cela n'a rien à voir avec l'histoire du chargement.
Cela est probablement dû au chargement historique
Oui, bien sûr, l'utilisation de la contrepartie iBarShift a révélé ce problème.
Si vous utilisez la fonction iBarShift que vous avez fournie, vous ne rencontrerez pas ce bogue, car un seul TF est utilisé dans cette fonction,
Et ce bug se produit lorsque vous utilisez des TF différents dans les fonctions CopyTime et Bars.
Mais Bars devrait fonctionner normalement à tout moment. Mais mon exemple montre qu'il existe un cas particulier, où iBar se bloque pendant des dizaines de secondes. Et cela n'a rien à voir avec l'histoire du chargement.
Je pense qu'il y a une tentative de synchronisation cyclique dans une situation où il n'y a pas de barres dans la plage demandée - Bars essaie de "travailler normalement" et abandonne ensuite par un timeout ou un nombre de tentatives de synchronisation.
Vous devez vérifier les valeurs vous-même pour éviter d'appeler Bars dans un tel cas.
C'est probablement dû au téléchargement de l'historique
Je ne suis pas d'accord. Il n'aurait pas été téléchargé à nouveau avant 22 secondes. De plus, je dispose de l'historique complet de toutes les TF chargées par un indicateur spécial.
S'il s'agissait d'un chargement, alors comment expliquer que les 31 premières mesures nécessitent un chargement et que les suivantes n'en nécessitent pas.
S'il s'agissait d'un sous-chargement, alors comment expliquez-vous que les 31 premières mesures nécessitent un sous-chargement et que les suivantes n'en ont pas besoin.
Extrait de la documentation : Lorsque vous demandez le nombre de barres dans une plage de dates donnée, seules les barres dont l'heure d'ouverture se situe dans cette plage sont prises en compte.
En conséquence, le prototype Bars() renvoie zéro, ce qui est interprété comme une absence d'historique et ::Bars() dans le cas du script, comme cela a été correctement noté dans un post précédent, se termine par un timeout ou un nombre de tentatives échouées.
Je pense qu'il y a une tentative de synchronisation cyclique lorsqu'il n'y a pas de barres dans la plage demandée - Bars s'efforce de "travailler normalement" et abandonne ensuite par dépassement de temps ou par nombre de tentatives de synchronisation.
La raison de ces cas est que vous ne devez pas appeler Bars manuellement.
C'est tout à fait possible.
Mais il y a beaucoup d'options.
Les barres sont une fonction très importante, et il est difficile de s'en passer. Pour être exact, vous pouvez vous en passer mais cela vous coûtera beaucoup de ressources.
Vous devez vous assurer qu'il fonctionne parfaitement.
Extrait de la documentation : Lorsque l'on demande le nombre de bars dans une plage de dates donnée, seuls les bars dont les heures d'ouverture sont comprises dans cette plage sont pris en compte .
En conséquence, le prototype Bars() renvoie zéro, ce qui est interprété comme une absence d'historique et le script, comme indiqué correctement dans un message précédent, se termine par un dépassement de délai ou un nombre de tentatives infructueuses.
Il est clair que c'est zéro.
Et quoi - est-il acceptable de prendre 22 secondes pour décider qu'il n'y a pas de barres dans une plage de temps donnée ?
Il y a un bug algorithmique évident dans l'implémentation interne de Bars.
Nous devrions envoyer une demande au Service Desk à ce sujet - le week-end approche et le sujet pourrait se perdre le lundi.
Clairement, zéro.
Est-il acceptable de prendre 22 secondes pour décider qu'il n'y a pas de barres dans un intervalle de temps donné ?
Il s'agit clairement d'un bug algorithmique dans l'implémentation interne de Bars.
Et je ne comprends pas comment vous faites la différence entre les barres zéro dans un intervalle de temps donné et ce zéro:
Extrait de la documentation : Si les données d'une série chronologique avec les paramètres spécifiés lors de l'appel de la fonction Bars() ne sont pas encore générées dans le terminal, ou si les données de la série chronologique ne sont pas synchronisées avec le serveur de négociation au moment de l'appel de la fonction, celle-ci renverra une valeur nulle.
En d'autres termes, comment puis-je faire la différence entre un résultat nul et une erreur nulle ?