NormalizeDouble paradoxe - page 2
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
La rupture du modèle est que même après normalisation, il y a toujours des queues !
Pas de queue après normalisation... N'induisez pas les gens en erreur.
Je n'entre pas dans .... mais j'ai
la situation est la suivante : je normalise un nombre double, je l'écris dans une variable globale du terminal, puis je le lis, je le normalise à nouveau et j'obtiens pile !
enfin - je n'ai pas le pouvoir d'attraper ces queues - je les ai simplement coupées de force en utilisant DoubleToStr(current,2)
Je n'entre pas dans .... mais j'ai
la situation est la suivante : je normalise un nombre double, je l'écris dans une variable globale du terminal, puis je le lis, je le normalise à nouveau et j'obtiens pile !
en conséquence - pas d'énergie pour attraper ces queues - je les ai juste prises et coupées de force en utilisant DoubleToStr(current,2)
Si vous normalisez la variable double, par exemple, à 5 caractères, alors la variable stockera 5 caractères, dans le cas des raprinters et autres, vous convertissez la variable à un type de données différent, ce qui peut provoquer des queues.
Mais il n'y a pas de queue dans le double après normalisation...
Pour ne pas avoir de plantage, il faut faire la normalisation aux points d'application, au cours des calculs, il ne faut pas...
Si vous normalisez une variable double à 5 chiffres par exemple, la variable stockera 5 chiffres, en cas de réimpression et autres choses, vous convertissez la variable en un autre type de données et une queue peut apparaître en conséquence.
mais il n'y a pas de queue dans le double après normalisation...
Pour ne pas avoir de crash, la normalisation doit être faite aux points d'application, vous ne pouvez pas la faire au cours des calculs...
alors il peut donner des queues exactement pendant cette conversion ?
ne savait pas
Merci !
C'est-à-dire que si je fais, par exemple, une transformation
alors il pourrait donner des queues précisément dans ce processus de conversion ?
ne savait pas.
Merci !
NormalizeDouble fonctionne exactement comme ceci (et a toujours fonctionné comme ceci depuis le premier MQL)
Le nombre est multiplié par 10 à la puissance des chiffres, converti en nombre entier (en éliminant la partie fractionnaire), puis divisé par 10 à la puissance des chiffres.
Quel est le problème ici ? Y a-t-il une rupture de modèle ?
La partie fractionnée est-elle jetée ? L'arrondi est effectué par.
NormaliserDouble(1.25,1) = 1.3
La partie fractionnée est-elle mise au rebut ? L'arrondi est effectué.
NormaliserDouble(1.25,1) = 1.3
Donc si je fais, par exemple, une conversion
alors il pourrait donner des queues précisément dans ce processus de conversion ?
ne savait pas.
Merci !
Pas vraiment. Système binaire != système décimal. Les décimales binaires sont 0,5 / 0,25 / 0,125 / 0,0625 / 0,03125, etc. Il n'est pas possible d'additionner tous les chiffres décimaux de ces briques. Par exemple, il est impossible de composer un nombre décimal 0,3 exactement (vous ne pouvez composer qu'une valeur approximative), dans le système binaire, il sera soit un peu moins, soit un peu plus. C'est ainsi que cette queue apparaît.
Seuls les nombres divisibles sans reste par 1/2^chaque puissance sont représentés avec précision.
En d'autres termes, nous déformons les chiffres lorsque nous essayons de représenter des nombres décimaux sous forme binaire.
Nous sommes habitués au fait que pour ne pas écrire exactement le résultat d'une opération, 1/3 devra arrondir. Mais dans le système ternaire, il existe une représentation exacte de l'opération == 0,1. Si notre système d'origine était ternaire et que le PC travaillait avec le système décimal, nous serions surpris du nombre de bits dérisoire lors de la reconversion en ternaire du nombre 0,1troïque.
Une telle analogie :
Nous avons l'habitude de ne pas écrire exactement le résultat d'une opération 1/3, nous devons arrondir. Mais dans le système ternaire, il existe une représentation exacte de l'opération == 0,1. Si notre système d'origine était ternaire et que le PC travaillait avec le décimal, nous serions surpris par des déchets en bits en reconvertissant en ternaire le nombre 0,1troïque.
C'est vrai.
Mais, pour une raison quelconque, même une calculatrice de poche peut lire un nombre en mémoire et renvoyer exactement ce qui a été écrit.
Vous écrivez une fraction 1,23 et vous obtenez exactement 1,23 sans queue.
Et voici l'astuce.
en théorie, l'utilisateur devrait être libre d'une routine telle que présenter le nombre en format binaire
<mode d'extraction désactivé>.