![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Ce qui me dérange, c'est que lorsque je calcule un nombre fractionnaire, que je le normalise, que je l'écris dans une variable, puis que je le lis et le normalise à nouveau, j'obtiens des queues.
par exemple
basis[0]=NormalizeDouble(sum_A,2);
GlobalVariableSet("Equity-"+portfolio_id,basis[0]);
...
current=NormalizeDouble(GlobalVariableGet("Equity-"+portfolio_id),2);
text = "Positions synchronized at " + current + " for portfolio: " + portfolio_name;
if(!automatic) MessageBox(text,""); else Print(text);
Maintenant, je l'ai changé en
text = "Positions synchronized at " + DoubleToStr(current,2) + " for portfolio: " + portfolio_name;
if(!automatic) MessageBox(text,""); else Print(text);
et il ne semble pas y avoir de queue, whew, whew, whew...
Je l'ai déjà écrit, je le répète - certains nombres n'existent pas en binaire. Il n'y a pas de 0,1, pas de 0,3 et bien d'autres. Peu importe le nombre de fois où vous écrivez double val = NormalizeDouble(0.1434, 1), vous n'obtiendrez jamais 0.1, car ce nombre n'existe pas.
Par exemple, les nombres sont représentés comme suit :
0,1 = 0,10000000000000001
0,2 = 0,20000000000000001
0,3 = 0,2999999999999999999999999
0,4 = 0,400000000000002
0,6 = 0,59999999999999998
mais
0,125 = 0,125
0,25 = 0,25
0,5 = 0,5
Si cela est très dérangeant, vous devez soit arrondir, soit écrire votre propre vélo pour représenter les nombres fractionnaires (il existe peut-être des bibliothèques, je ne suis pas intéressé) qui n'utiliseront pas le fpu.
Et aucune queue n'est ajoutée lors de la conversion en chaîne, elle est présente au départ.
donc j'ai résolu ma question, nous pouvons fermer le sujet.
solution : il faut forcer les arrondis, même après normalisation
tout à fait possible... mais en termes de résultat final - il y a des queues !
...
Il n'y a pas de queue après la normalisation.
Je pense que vous induisez l'homme en erreur. Comment ça, il n'y a pas de queue après normalisation ? Il ne peut y avoir de queue que dans la chaîne que nous avons obtenue à partir d'un nombre et dont nous avons arrondi la valeur (arrondi déjà dans la chaîne, pas dans le double). Mais il y a des queues après NormalizeDouble().
Mauvaise solution. Pour arrondir, il faut multiplier, arrondir, diviser. Après la dernière division, le nombre sera non normalisé.
Qu'entendez-vous par "normalisation" ? Stringo disait ici que l'algorithme est quelque chose comme ça :
Je pense que vous induisez l'homme en erreur. Comment ça, il n'y a pas de queue après normalisation ? Il ne peut y avoir de queue que dans la chaîne que nous avons obtenue à partir d'un nombre et dont nous avons arrondi la valeur (arrondi déjà dans la chaîne, pas dans le double). Mais après NormalizeDouble() il y a des queues.
Qu'entendez-vous par "normalisation" ? Stringo disait ici que l'algorithme est quelque chose comme ça :
Je te pose une question précise et tu me jettes de l'eau. Est-il normal d'expliquer et d'argumenter son point de vue ?
Lire les manuels et la documentation à haute voix ou quoi ? Ou lire le dictionnaire à haute voix, à propos du mot "environ" ?