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
Obsolète
La bibliothèque standard dispose d'une fonction de normalisation des prix tenant compte de la granularité.
La bibliothèque standard dispose d'une fonction de normalisation des prix tenant compte de la granularité.
Je commençais à supposer que NormalizeDouble(new_lot-sum_lots,Lots_Digits) ; il ne produit pas exactement 0 et stocke un peu de queue.
Si les variables new_lot et sum_lots sont égales, alors la différence est exactement 0. Mais on ne sait pas comment vous les calculez, elles peuvent en effet être inégales lors du calcul, d'où la différence non nulle. Fais la même chose comme ça :
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
Si les variables sont égales dans un nombre spécifié de chiffres, alors la différence sera strictement égale à 0.
Si les variables new_lot et sum_lots sont égales, alors la différence est exactement 0. Mais on ne sait pas comment vous les calculez, elles peuvent en effet être inégales lors du calcul, d'où la différence non nulle. Fais la même chose comme ça :
NormalizeDouble(new_lot, Lots_Digits) - NormalizeDouble(sum_lots, Lots_Digits).
Si les variables sont égales dans le nombre de chiffres spécifié, la différence sera strictement égale à 0.
Encore une fois à propos des arrondis......
Veuillez me conseiller sur la situation (ne jetez pas de tomates, je suis un humanitaire),
il existe une telle variable :
double delta=NormalizeDouble(new_lot-sum_lots,Lots_Digits);
if(delta>0) delta-=OrderLots();
if(delta<0) delta+=OrderLots();
Le delta est normalisé à l'origine,
Les lots de commande devraient probablement renvoyer des dubs normalisés,
mais d'une manière ou d'une autre, à de rares occasions, j'obtiens des chiffres comme 2.775557561562891e-17
Donc c'est presque zéro mais pas zéro.......
Première question : est-ce normal ?
...
Je l'ai relu attentivement. Ce n'est pas normal. Si fonction NormalizeDouble :
- La partie entière est sélectionnée - I
- La partie fractionnaire est sélectionnée - F
- F = F * 10^chiffres
- F = F (+ ou - selon le signe) 0,5
- F = (partie entière de F) / 10^chiffres
- résultat = I + F
alors le résultat deNormalizeDouble(new_lot - sum_lots, Lots_Digits) devrait être strictement nul si new_lot et sum_lots sont égaux dans le nombre de chiffres spécifié. Dans de rares cas, il peut y avoir une différence de 1 dans le dernier chiffre (la raison est dans les points 4 et 5), mais le résultat 2.775557561562891e-17 est étrange, il ne devrait pas l'être.J'ai écrit un petit code tutorial (j'avais envie de farfouiller moi-même) qui montre les entrailles d'un nombre flottant. Si quelqu'un est intéressé, vous pouvez l'exécuter (code C++, vous pouvez utiliser un compilateur en ligne. Ici https://goo.gl/tP691X, par exemple)
La sortie à f == 0.5 + 1/(2^24). 1/(2^24) est le chiffre le moins significatif de la mantisse à un degré donné :
Degré = 126 - 127 = -1
mantisse = 1,0000000000000000000000001
Décaler la mantisse au degré -1 = 0,1000000000000000000001 = 1^(-1) + 1^(-24) = 1/(2^1) + 1/(2^24) = 0,5 + 0,00000005960464478 = 0,50000005960464478
En tant que théorie https://habrahabr.ru/post/112953/.
SZZ : ce compilateur en ligne est plus agréable que http://rextester.com/l/cpp_online_compiler_gcc
J'ai écrit un petit code tutorial (j'avais envie de farfouiller moi-même) qui montre les entrailles d'un nombre flottant. Si quelqu'un est intéressé, vous pouvez l'exécuter (code C++, vous pouvez utiliser un compilateur en ligne. Ici https://www.tutorialspoint.com/compi le_cpp11_online.php, par exemple)
Vous pouvez également l'exécuter dans MQL5 - remplacez c[Pos] par _R(f)[(char)Pos] (ou _R(f).Bytes[Pos]) en connectant cette bibliothèque.
SZ
Résultat
Qu'est-il arrivé à la mantisse ?
32 est le code ascii du problème. Il semble que la bibliothèque avec l'erreur n'a pas une version char. Je pense que nous devons supprimer les problèmes entre les valeurs de mantisse. Ou peut-être qu'au lieu de ' ', il faut écrire " " ?
Qu'est-il arrivé à la mantisse ?
32 est le code ascii du problème. On dirait une bibliothèque avec un bug. Je pense que nous devons supprimer les problèmes entre les valeurs de mantisse. Ou peut-être qu'au lieu de ' ', il faut écrire " " ?
Le fmtprntl.mqh n'est pas à moi, donc je ne peux pas en être sûr.
Je ne veux pas m'embêter, alors pour vos valeurs d' octets imprimés f
Un effet secondaire connexe.
Ça s'est avéré être pratique. Mais à l'origine, elle n'était pas destinée à être utilisée de cette manière.
Il existe des fonctions spéciales pour imprimer des nombres réels avec la précision requise.
Dites-moi pourquoi vous devez arrondir les nombres réels dans le processus de calcul ? Car dans ce cas, vous perdez en précision de calcul !
Nous parlons de la comparaison correcte des prix, des arrêts, des lots...
Vous avez besoin d'une certaine précision ici.