MT5 et la vitesse en action - page 23
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
Au cas où quelqu'un ne comprendrait pas, c'est la bibliothèque fxsaber qui provoque le freinage lorsqu'elle est appliquée dans le code de quelqu'un d'autre.
Au lieu de le signaler explicitement, il a commencé à jouer le jeu des exemples suicidaires de freinage et de glissement de plate-forme. Et lorsqu'il a eu l'occasion de s'attaquer à la vraie cause et d'aplanir le problème, il ne l'a pas saisie.
Pour des raisons d'optimisation locale, il empoisonnait le cache de l'historique de l'application principale.Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
MT5 et la vitesse en action
fxsaber, 2020.09.02 00:02
Il y avait un code MQL5 propre et reproductible par beaucoup. La chronologie du fil de discussion étudie d'abord, au lieu de jouer à la théorie du complot, que quelqu'un a tellement besoin de vous qu'il est prêt à passer son temps sur vous pour faire du mudsling.
Tu fais un excellent travail en tant que dinde. Il n'y a pas eu de discussion sur les bibliothèques ici spécifiquement dans le fil de discussion car ce n'est pas constructif.
Le fait est que si quelqu'un s'aventure à utiliser des bibliothèques partagées où le paramètre from-input ne coïncide pas, il sera freiné. Il n'en est fait mention nulle part dans la documentation. Au moins quelque chose sur ce sujet a été extrait de vous avec des pinces. Et quand c'était fait, ils ont commencé à vous accuser de tricher.
Cette fonctionnalité de MQL devrait être écrite dans la branche Documentation et dans la branche Fonctionnalités. Exécutez les scripts MQL5 propres de cette branche sur les builds correspondant aux dates de leur création. Apparemment, tant de corrections ont été faites à l'aveuglette, juste au cas où.
Vous faites un excellent travail en tant qu'indépendant. Aucune bibliothèque n'a été spécifiquement mentionnée ici dans le fil de discussion, car ce n'est pas constructif.
Parce que vous avez fait de votre mieux pour ne pas parler de vos bibliothèques. En présence de ces bibliothèques. Avec l'opposition constante de "le mien est plus rapide". Vous avez donc habilement masqué l'autodafé en mettant en avant "regardez comme c'est lent".
Le fait est que si l'on ose utiliser ensemble des bibliothèques où le paramètre d'entrée n'est pas le même, on obtiendra des décalages. Il n'en est fait mention nulle part dans la documentation. Au moins quelque chose sur ce sujet a été extrait de vous avec des pinces. Et quand c'était fait, ils ont commencé à vous accuser de tricher.
Cette fonctionnalité de MQL devrait être écrite dans la branche Documentation et dans la branche Fonctionnalités. Exécutez les scripts MQL5 propres de cette branche sur les builds correspondant aux dates de leur création. Apparemment, tant de corrections ont été faites à l'aveuglette, juste au cas où.
La documentation de HistorySelect indique clairement :
Lorsque vous travaillez avec d'énormes volumes (et ce n'est pas pour rien que vous avez montré des milliers et des dizaines de milliers de transactions dans l'historique), qui nécessitent un accès atomique/snapshot, vous devez comprendre leur coût.
D'autant plus que j'ai expliqué les détails techniques de ces caches de manière très détaillée dans ce fil de discussion.
Avez-vous essayé pour rien de randomiser chaque échantillon et d'empoisonner le cache autant que possible ? Pour le bien de votre position, une autodestruction est de mise ?
Parce que vous avez fait tout ce que vous pouviez pour que vos bibliothèques restent discrètes. C'est pourquoi vous avez habilement masqué les bugs auto-infligés en affichant "regardez comme il est lent".
99% des bugs sont trouvés de cette façon. Le comportement étrange se trouve d'abord dans le gros code. La localisation permet alors de trouver la cause. J'étais plus préoccupé par les freins.
fonction commerciale. Les problèmes sont presque partout.
La documentation de HistorySelect indique explicitement :
Je me demande qui a vu quelque chose entre les lignes dans ce texte ? Personnellement, j'ai compris (avant cette branche), que HistoryDealSelect et HistoryOrderSelect doivent être écrits comme ceci.
Sinon, vous êtes assuré de rencontrer des décalages.
Lorsque vous travaillez avec d'énormes volumes, nécessitant un accès atomique/snapshot, vous devez comprendre leur coût.
D'autant plus que j'ai expliqué les détails techniques de ces caches de manière très détaillée dans ce fil de discussion.
J'ai recueilli les informations nécessaires dans ce fil.
Avez-vous essayé pour rien de randomiser chaque échantillon et d'empoisonner le cache autant que possible ? Pour le bien de votre position, une autodestruction est de mise ?
Vous pouvez tout voir par ordre chronologique dans ce fil. Le problème a été montré à l'origine sans aucun aléa.
Ce fil est un grand testament de la façon dont vous pouvez déformer les mots de votre adversaire. Toutes les sources et leurs résultats sont enregistrés ici.
Pourquoi le terminal ne peut-il pas simplement augmenter le cache lorsque l'historique complet est à nouveau demandé, récupérer et mettre en cache la plage manquante ? Cela semble résoudre le problème. Après tout, lors de la demande de bars/tickets, des paquets de données manquants sont renvoyés, il existe donc un mécanisme pour cela.
Pourquoi le terminal ne peut-il pas simplement augmenter le cache lorsque l'historique complet est à nouveau demandé, récupérer et mettre en cache la plage manquante ?
Cela a déjà été fait.
Mais si entre HistorySelect( 0, INT_MAX ) appelleHistorySelect( autre_temps, ... ), le cache sera reconstruit à partir d' autre_temps et la prochaine requêteHistorySelect( 0, ... ) entraînera une nouvelle construction du cache (sera plus lente).
Cela a déjà été fait.
Mais si entre les appels de HistorySelect( 0, INT_MAX ) nous appelonsHistorySelect( autre_temps, ... ), le cache sera reconstruit à partir d' autre_temps et la prochaine requêteHistorySelect( 0, ... ) entraînera une nouvelle construction du cache (ce sera plus lent).
Si vous l'avez fait, c'est bien, la seule question est alors celle de la commodité du travail avec les données reçues, à condition que le cache soit constitué.
Je n'ai pas compris les opérations de trading aussi profondément, mais si la plage de requête change, il n'y a pas de possibilité de rechercher rapidement des données dans l'historique sans force brute totale ?
Je ne suis pas très au fait des échanges, mais si l'étendue de la requête change, il n'y a aucun moyen de rechercher rapidement des données dans l'histoire sans une énumération complète ?
Quel est l'intérêt de ces connaissances si vous ne les utilisez pas ?
Pas de problème pratique = pas de question.
OrderExist et PositionExist sont des fonctions spéciales optimisées qui évitent de boucler stupidement sur tous les ordres ou positions à la recherche d'entrées par symbole, type de transaction et medzhik.
Le résultat est un ensemble de billets.
Les programmes peuvent économiser beaucoup d'argent en utilisant ces fonctions. Surtout lorsqu'on appelle des positions ouvertes et des ordres en masse, de manière constante et répétée dans des boucles de dépassement.
Nous mettrons en œuvre des fonctions plus efficaces pour accéder à des données commerciales massives à l'avenir.
La langue sera également considérablement renforcée et simplifiée grâce à des fonctionnalités plus puissantes.
"OrderExist et PositionExist" - non trouvé dans la documentation, où lire à leur sujet ?
Très probablement après la prochaine version (actuellement en version bêta).