Algorithmes, méthodes de résolution, comparaison de leurs performances - page 6
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
Qu'est-ce qui ne va pas avec un tableau normal d'ints ? Pourquoi les thongs....
Parce que nous ne savons pas à l'avance combien de transactions l'EA va effectuer. Nous devons allouer de la mémoire pour le tableau à l'avance, mais nous ne savons pas combien.
Nous avons donc dû trouver une solution rapide et courte, qui n'occupe pas de mémoire inutile.
Pas vraiment.
...
Encore une fois, imaginez qu'au lieu d'une chaîne de caractères, vous utilisez une classe pour stocker un tableau dynamique de graphiques - et vous pensez que c'est rapide ?
Je ne connais pas le fonctionnement interne des fonctions de chaîne, mais les mesures de vitesse des fonctions montrent qu'il faut moins de 100 microsecondes pour trouver et renvoyer un medjic à partir d'une chaîne de milliers de medjics.
Cela me semble très rapide. Il est peu probable qu'il soit plus rapide.
Parce que nous ne savons pas à l'avance combien de transactions l'EA va effectuer. Nous devons allouer de la mémoire pour le tableau à l'avance, mais nous ne savons pas combien.
C'est pourquoi nous avons dû trouver une solution qui soit rapide et courte et qui ne prenne pas de mémoire inutile.
A propos du rapide. Mesurez la vitesse d'extraction des 24000 milliers de medjics. Vous serez désagréablement surpris.
C'est fait :
Votre exemple ne peut plus être corrigé :)
Que se passe-t-il si la taille des rangs est insuffisante ?
Votre exemple peut avoir 32767 enregistrements (transactions), alors essayez de comparer les derniers magik écrits et lus.
Encore une fois, vous ne comprenez pas de quoi nous parlons. Le système de négociation (MetaTrader ou bourse) attribue un numéro de transaction. Par numéro de transaction, on entend non pas le numéro de série de la transaction, mais précisément le ticket, renvoyé par la fonctionHistoryDealGetTicket. Donc, en tenant compte de cela et en modifiant votre exemple.
Ce n'est pas un problème. Demain, je ferai une deuxième version qui fonctionnera avec le ticket.
Cette version est également pratique pour le commerce.
Sur le compte rapide. Mesurez la vitesse de récupération des 24 millions de medjits. Vous seriez désagréablement surpris.
A tout moment, on n'a besoin que d'un seul Medjic, non ?
Extraire un medjack, accéder à toute information relative à la commande.
Pourquoi devons-nous extraire 24 000 medjiks en même temps ?
Qu'est-ce que je fais ici ? Avec qui est-ce que je perds mon temps ? Je ferais mieux d'aller boire un verre plus fort.
p.s. Oh, oui, vous avez encore une erreur. Si MathRand au troisième appel renvoie par exemple le nombre 1000 et écrit _3_1000_, quel genre de medjic sera trouvé pour une affaire avec le nombre ordinal 1000 ?Votre exemple ne peut pas être corrigé maintenant :)
Que se passe-t-il si la taille des rangs est insuffisante ?
Votre exemple peut avoir 32767 enregistrements (transactions), alors essayez de comparer les derniers magik écrits et lus.
Merci de m'avoir signalé la limite de longueur des lignes.
Vous pouvez commencer à écrire la deuxième ligne. Puis le troisième et ainsi de suite... :)
Je ne connais pas l'implémentation interne des fonctions de chaîne, mais une mesure du temps d'exécution des fonctions montre qu'il faut moins de 100 microsecondes pour trouver et renvoyer un medjic à partir d'une chaîne totale de milliers de medjics.
Je pense que c'est très rapide. Je ne pense pas que ça puisse être plus rapide.
En résumé, une chaîne d'un caractère est uncaractère dont le code est compris entre 0 et 255 et qui pèse 1 octet... et qu'on lui a alloué juste assez de mémoire pour contenir 256 valeurs, 257 ne tiendra pas là, il reviendra à la première.
Dans toute page, chaque caractère est un nombre de 0 à 255... donc on prend le nombre 10000000 - il pèse 4 octets, on le convertit en chaîne de caractères "10000000" puis pour chaque caractère on alloue de la mémoire comme pour une carte individuelle de 0 à 255... 8 octets au total. Il n'y a pas d'économie de mémoire nulle part.