Bogue MQL5 lors du travail avec l'accès aux séries chronologiques iClose/iOpen, etc. - page 10
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
C'est absurde.
C'est absurde.
Tant que "soudainement" (c), il n'est pas question de limiter les performances du système (quel qu'il soit).
Ces derniers temps, je me suis penché de plus près sur le traitement des données OnCalculate et tick. Il a été écrit plus haut que tout est fait pour éviter de "geler" les indicateurs mal écrits, mais si nous voulons vraiment traiter l'ensemble du flux de données en tick depuis le précédent appel de OnCalculate, alors en cas de mouvement rapide des prix (et de retour en arrière), nous devrions obtenir un tableau assez "profond", y a-t-il des limites à la profondeur du tableau en tick ?
Je n'aimerais pas entendre une réponse telle que "OnCalculate recevra un ou plusieurs tick(s) d'accumulation..., pour optimiser...".
Qui analyse déjà les données des tics, y a-t-il lieu de s'inquiéter ?
Ces derniers temps, je me suis intéressé à OnCalculate et au traitement des données en tic-tac. Il a été écrit plus haut que tout est fait pour éviter de "geler" les indicateurs mal écrits, mais si nous voulons vraiment traiter l'ensemble du flux de données en tick depuis le précédent appel de OnCalculate, alors en cas de mouvement rapide des prix (et de retour en arrière), nous devrions obtenir un tableau assez "profond", y a-t-il des limites à la profondeur du tableau en tick ?
Je n'aimerais pas entendre une réponse telle que "OnCalculate recevra un ou plusieurs tick(s) d'accumulation..., pour optimiser...".
Qui analyse déjà les données des tics, y a-t-il des raisons pour de telles craintes ?
En 2008-2009, Renat a écrit une fois qu'il n'y a pas de bonheur dans les tics, il a donné l'exemple d'un expert. Les tics sont ignorés de toute façon. Si vous en avez besoin, obtenezhttps://www.mql5.com/ru/docs/series/copyticks sur chaque appel, mais vous manquerez toujours le sommet ou le creux 50/50 que vous voulez entrer.
Je vais juste faire un saut ici pour le bien de la publicité. J'essaie de comprendre pourquoi ça ne marche plus depuis un mois maintenant :
J'attends la nouvelle version de l'ouverture.
Reprise des questions relatives à l'optimisation et au chargement des données historiques.
1. Le problème du fonctionnement correct des fonctions iClose/iOpen, et dans ce cas iTime, existe et je pense qu'il est absurde d'espérer que tout sera parfait. Peut-être faudrait-il tout simplement les supprimer de MQL5 pour éviter de refaire les mêmes erreurs ? (J'ai un problème, mais je n'ai pas le temps de le décrire, car j'ai trouvé une solution, un autre "twist")
Il existe peut-être une solution, mais j'aimerais qu'elle soit documentée et non pas une autre entorse à la communauté MQL5. Nous parlons de la manière de traiter les requêtes asynchrones, qui à leur tour synchronisent les bases de données locales par exemple :
La phrase clé est"Après avoir terminé la synchronisation, le prochain appel de CopyTicks() retournera tous les ticks demandés. ", messieurs comment savez-vous que la synchronisation est terminée ? ??? Il est écrit comme si avant la fin de la synchronisation CopyTicks() retournait par exemple -1, mais ce n'est pas le cas.En conséquence, après quelques rechargements de l'indicateur, la base de données se synchronise et nous obtenons vraiment l'ensemble des données, mais si je ne recharge pas l'indicateur, je n'obtiens pas cet ensemble de données, car je ne connais pas le résultat de la fin de cette fichue synchronisation.
Un exemple frappant ont été les derniers coups, il y avait un mouvement brusque sur EURUSD, bien que l'indicateur était sur tout ce temps et a en quelque sorte rendu cette période normalement, mais après que je l'avais rechargé (changé les paramètres d'entrée), l'indicateur a commencé à refléter l'information incorrectement, respectivement les recherches d'erreurs dans l'indicateur ont été lancées (recompilé et rechargé plusieurs fois) mais rien n'a aidé, et puis ce "miracle" s'est produit, "Lorsquevous appelez CopyTick() à partir d'un indicateur, il retournera immédiatement les ticks disponibles pour le symbole, et commencera également la synchronisation de la base de ticks", peut-être devriez-vous créer (ou avoir) une fonction qui peut nous dire qu'à ce moment la synchronisation de la base de données locale n'est pas terminée, cette fonction faciliterait notre tâche et nous permettrait d'écrire un meilleur produit final pour le marché.
P.S. : La fonction SymbolInfoTick n'a malheureusement pas cette fonctionnalité.
Malheureusement, cet exemple ne fonctionne pas toujours :
Pour être exact, cela fonctionne 1 à 2 fois sur 10.
Mais dans la situation décrite ci-dessus, cela n'a pas fonctionné une seule fois.
Encore une question, la base de données est-elle mise à jour en temps réel ?
Comme je l'ai écrit ci-dessus, pendant toute la période qui a posé problème, l'indicateur a fonctionné, c'est-à-dire que la fonction CopyTicks() a été appelée régulièrement, mais il s'avère qu'elle n'a eu aucun effet sur la base de données locale..... C'est bizarre....
En 2008-2009, Renat a écrit une fois qu'il n'y a pas de bonheur dans les tics, en donnant l'exemple d'un expert. Les tiques sont sautées comme c'est le cas. Si nécessaire, obtenezhttps://www.mql5.com/ru/docs/series/copyticks à chaque appel, mais vous manquerez toujours le sommet/le creux 50/50 auquel vous voulez accéder.
Reprise des questions relatives à l'optimisation et au chargement des données historiques.
1. Le problème du fonctionnement correct des fonctions iClose/iOpen, et dans ce cas iTime, existe probablement et il n'y a aucune raison d'espérer que tout sera parfait. Peut-être peut-on simplement les supprimer de MQL5 pour éviter de refaire les mêmes erreurs encore et encore ? (J'ai un problème, mais je n'ai pas le temps de le décrire, car j'ai trouvé une solution, un autre "twist")
Il existe peut-être une solution, mais j'aimerais qu'elle soit documentée et non pas une autre entorse à la communauté MQL5. Nous parlons de la manière de traiter les requêtes asynchrones, qui à leur tour synchronisent les bases de données locales par exemple :
La phrase clé est"Après avoir terminé la synchronisation, le prochain appel de CopyTicks() retournera tous les ticks demandés. ", messieurs comment savez-vous que la synchronisation est terminée ? ??? Il est écrit comme si avant la fin de la synchronisation CopyTicks() retournait par exemple -1, mais ce n'est pas le cas.En conséquence, après quelques rechargements de l'indicateur, la base de données se synchronise et nous obtenons vraiment l'ensemble des données, mais si je ne recharge pas l'indicateur, je n'obtiens pas cet ensemble de données, car je ne connais pas le résultat de la fin de cette fichue synchronisation.
Un exemple frappant ont été les derniers coups, il y avait un mouvement brusque sur EURUSD, bien que l'indicateur était sur tout ce temps et a en quelque sorte rendu cette période normalement, mais après que je l'avais rechargé (changé les paramètres d'entrée), l'indicateur a commencé à refléter l'information incorrectement, respectivement les recherches d'erreurs dans l'indicateur ont été lancées (recompilé et rechargé plusieurs fois) mais rien n'a aidé, et puis ce "miracle" s'est produit, "Lorsquevous appelez CopyTick() à partir d'un indicateur, il retournera immédiatement les ticks disponibles pour le symbole, et commencera également la synchronisation de la base de ticks", peut-être devriez-vous créer (ou avoir) une fonction qui peut nous dire qu'à ce moment la synchronisation de la base de données locale n'est pas terminée, cette fonction faciliterait notre tâche et nous permettrait d'écrire un meilleur produit final pour le marché.
P.S. : La fonction SymbolInfoTick n'a malheureusement pas cette fonctionnalité.
Que renvoie SERIES_SYNCHRONIZED dans ce cas ?