Obtenir le nombre de décimales de n'importe quel nombre (pas seulement les guillemets) en contournant Digits() dans MQL4 et MQL5 - page 21
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
Sur la route pour le moment. Vous pouvez l'essayer vous-même. L'idée est d'utiliser des unions avec des tableaux de structures de différentes tailles, par exemple 10, 100, 1000, 10000...
Cette idée a été utilisée. Dans ce cas
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Obtenir le nombre de décimales de n'importe quel nombre (pas seulement les guillemets) en contournant Digits() dans MQL4 et MQL5
fxsaber, 2018.12.08 16:25
J'ai essayé différentes tailles, bien sûr. Pour une raison quelconque, ils n'affectent pas le résultat.
Cette idée a été utilisée. Ce faisant
Vous pouvez tout voir dans le livre de référence.Oui, j'ai vérifié. C'est étrange que ça n'ait aucun effet.
Il y a une ligne dans la source qui contrôle la taille
Vous pouvez modifier cette valeur et voir le résultat. Si la valeur est supérieure à cent, la vitesse n'augmente pas. C'est en fait facile à expliquer, car le même nombre d'éléments est copié au total. Et les décalages associés aux petites portions de copie sont éliminés.
Je crains que nous ne soyons déjà bloqués sur la performance maximale.
Oui, je suis d'accord.
Je l'ai essayé - le même résultat que dans votre TicksToIntArray_fxsaber4/IntArrayToTicks_fxsaber4
Vous avez le code source, vous pouvez le mesurer vous-même.
Alors, mesurez-la. Je suis presque sûr que non, donc je ne vois pas l'intérêt de perdre du temps sur l'article ou la mesure.
Je crains que nous ne soyons déjà à la limite de la performance.
Pour être honnête, je suis très surpris qu'ils aient réussi à être si proches de memcpy. Ce n'est pas possible. Quelque chose ne va pas.
Je crains que nous soyons déjà coincés avec la performance maximale.
Je crois que je comprends une très grave erreur de calcul de votre part.
Votre BANCH sélectionne un minimum de 50 séries absolument identiques.
Mais le compilateur est un gros malin et paresseux. Il ne fera pas le même travail 50 fois et optimisera le code. C'est pourquoi vous devriez au moins changer les matrices à chaque passage. Vous pouvez aussi remplacer 50 par 1 et augmenter le nombre d'essais. Les résultats seront alors bien différents et plus objectifs.
Quand la différence par rapport à memcpy est de 40% c'est plus plausible
Je me demande si la compression du tableau aura un effet. Un tableau de ticks peut être compressé par un facteur de 10-12. La seule question qui se pose est de savoir si cela permettra de gagner le temps nécessaire à l'envoi et à la réception par le biais de la ressource.
Je crois que je comprends une très grave erreur de calcul de votre part.
Votre BANCH sélectionne le minimum de 50 exécutions absolument identiques.
Mais le compilateur est un gros malin et paresseux. Il ne fera pas le même travail 50 fois, il optimisera le code.
Le code est écrit de manière à ce qu'il fasse exactement ce qu'il est censé faire. Le compilateur ne pourra pas affecter la vitesse de memcpy, mais les résultats de ses passages sont les suivants
Une boucle d'une passe
Sur 50
Le code est écrit de manière à ce qu'il fasse exactement ce que vous voulez qu'il fasse. Le compilateur n'est pas en mesure d'affecter la vitesse de memcpy, mais les résultats des passes sont les suivants
Une boucle d'une passe.
Sur 50.
Alors, mesurez-la. Je suis presque sûr que non, donc je ne vois pas l'intérêt de perdre du temps avec l'article ou la mesure.
Je n'ai pas à le faire.