Erreurs, bugs, questions - page 2822
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 peut-être plus rapide, mais c'est tout simplement faux.
Avez-vous essayé vous-même ?
Essayez-le :
Sortie :
devrait être 12346, parce qu'il s'agit d'un plafond ("Renvoie la valeur numérique entière la plus proche de la valeur ci-dessus")le premier cas est 12345, parce que les chiffres significatifs en type double sont 17, alors que vous avez 18
Vraiment, vous ne pouvez pas comparer les doubles. C'est une règle stricte.
Bien sûr, il est possible et parfois même nécessaire de comparer directement les doubles entre eux.
Par exemple, OnTick est parfois appelé un trillion de fois pendant l'optimisation. Afin de comprendre s'il faut ou non exécuter une limite en attente, le testeur intégré compare le prix actuel du symbole correspondant et le prix limite. Il le fait pour chaque ordre en attente avant chaque appel OnTick. C'est-à-dire que ces contrôles sont effectués des dizaines et des centaines de milliards de fois.
Et cela se fait à chaque fois par la normalisation. Eh bien, c'est un horrible gaspillage de ressources informatiques. Puisque les prix des ordres en attente et du symbole sont préalablement normalisés. Par conséquent, ils peuvent et doivent être comparés directement les uns aux autres.
Le testeur MQL personnalisé surpasse facilement le testeur natif intégré en termes de performances.
fxsaber:
Bien sûr, il est possible et parfois même nécessaire de comparer directement les doubles entre eux.
Par exemple, OnTick est parfois appelé un trillion de fois pendant Optimize. Le testeur intégré, afin de comprendre s'il faut exécuter ou non un appel limite en attente, compare le prix actuel du symbole correspondant et le prix de l'appel limite. Il le fait pour chaque ordre en attente avant chaque appel OnTick. C'est-à-dire que ces contrôles sont effectués des dizaines et des centaines de milliards de fois.
Et cela se fait à chaque fois par la normalisation. Eh bien, c'est un horrible gaspillage de ressources informatiques. Puisque les prix des ordres en attente et du symbole sont préalablement normalisés. Par conséquent, ils peuvent et doivent être comparés directement les uns aux autres.
Le testeur personnalisé MQL surpasse facilement le testeur intégré natif en termes de performances.
NormalizeDouble() est une fonction très coûteuse. Par conséquent, vous feriez mieux de l'oublier.
Voici un script qui démontre la différence entre NormalizeDouble() et normalize with int :
résultat :
SZZ la normalisation par int est également plus précise (vous pouvez le voir par le nombre de neuf après le dernier chiffre de la normalisation - surligné en bleu).NormalizeDouble() est une fonction très coûteuse. C'est pourquoi il est préférable de l'oublier.
Voici un script qui démontre la différence entre NormalizeDouble() et normalize with int :
résultat :
SZZ la normalisation par int est encore plus précise (vous pouvez le voir par le nombre de neuf après le dernier chiffre de la normalisation - surligné en bleu).et si la somme n'est pas faite via le double, mais via le long, alors le résultat est encore plus impressionnant, puisque la somme via le int (multiplication et arrondi suivi de la division de la somme finale) se calcule plus rapidement que la somme normale du double.
résultat :
Et si la somme n'est pas effectuée via un double, mais via un long, le résultat est encore plus impressionnant, car la somme via un int (multiplication et arrondi, suivi de la division de la somme totale) est plus rapide qu'une somme double normale.
résultat :
Décimal pour l'addition de la comparaison.
Mauvais lien, ce n'est pas une implémentation complète.
Et cela se fait par la normalisation à chaque fois. Eh bien, c'est un terrible gaspillage de ressources informatiques.
Car même si les prix ne sont pas normalisés, le contrôle est simplement effectué sans aucune normalisation :
Étant donné que les prix sont des multiples du ticksize
De plus, la normalisation par int s'avère également plus précise (vous pouvez le constater par le nombre de neuf après le dernier chiffre de la normalisation - surligné en bleu).
Le test est incorrect. Pourquoi divisez-vous par 100000.0 une seule fois à la fin ? Cela devrait être fait à chaque itération et ensuite additionné. C'est une comparaison juste. Mais ce n'est pas du tout une normalisation - vous avez juste optimisé votre algorithme de test. Naturellement, il sera plus rapide et plus précis (car l'erreur accumulée est réduite).
Comment le savez-vous ?
Parce que vous pouvez entrer des prix non normalisés dans le testeur et il les traitera de manière identique.
Après tout, même si les prix ne sont pas normalisés, la vérification se fait facilement sans aucune normalisation.
Par normalisation j'entends dans ce cas, un seul algorithme standard, après l'avoir appliqué, vous pouvez directement comparer les doubles de ce standard.
Le testeur ne compare donc pas directement les doubles. Il le fait par NormalizeDouble, ticksize ou autre chose. Mais certainement pas par une comparaison directe des doubles. Et ce n'est pas du tout rationnel.
Bien sûr, il est possible et parfois même nécessaire de comparer directement les doubles entre eux.
Par exemple, Optimize OnTick est parfois appelé un trillion de fois. Le testeur intégré, afin de comprendre s'il faut exécuter ou non un appel limite en attente, compare le prix actuel du symbole correspondant et le prix de l'appel limite. Il le fait pour chaque ordre en attente avant chaque appel OnTick. C'est-à-dire que ces contrôles sont effectués des dizaines et des centaines de milliards de fois.
Et cela se fait à chaque fois par la normalisation. Eh bien, c'est un horrible gaspillage de ressources informatiques. Puisque les prix des ordres en attente et du symbole sont préalablement normalisés. Par conséquent, ils peuvent et doivent être comparés directement les uns aux autres.
Le testeur MQL personnalisé ne bat pas le testeur intégré natif en termes de performances.
J'ai donc décidé de vérifier la version insensée des performances.
Et le résultat était surprenant.
La comparaison, même d'un double pré-normalisé, est encore plus lente en moyenne que lorsque le double est comparé par epsilon ou par conversion en int.
Le résultat :
Je n'exclus pas qu'une grande partie dépende de la nouveauté et de l'architecture du processeur, et pour quelqu'un le résultat peut être différent.
Pour vous dire la vérité, je ne comprends même pas pourquoi cela se produit.
Il semble que le compilateur n'ait rien à optimiser avec la somme des nombres aléatoires. Vous ne pouvez pas mettre les arrondis hors parenthèses.
Il semble que la comparaison double dans le processeur soit une commande
. En comparant par epsilon (la manière la plus rapide), nous avons toujours une opération de comparaison de deux doubles, mais en plus nous avons un appel de fonction avec passage de trois paramètres et une opération de soustraction.
La performance de l'opération de comparaison de deux doubles dépend-elle des valeurs des variables elles-mêmes ? J'en doute.
Bon sang, je ne comprends pas. Aidez-moi, qu'est-ce que je n'ai pas pris en compte ou qu'est-ce que j'ai fait de travers ?
J'ai décidé de vérifier la version du speed rambling.
Et le résultat était surprenant.
La comparaison, même d'un double pré-normalisé, est en moyenne encore plus lente que si le double est comparé par epsilon ou par conversion en int.
Le résultat :
Je n'exclus pas que beaucoup dépende de la nouveauté et de l'architecture du processeur et que certains programmeurs puissent obtenir un résultat différent.