Arrondir les nombres dans MT4 via NormalizeDouble - page 15

 
pavlick_:
Certains nombres ne peuvent être représentés que par une fraction infinie, comme 1/3 dans le système décimal. Mais 1/3 n'est pas une fraction infinie dans le système tertiaire, là il == 0,1. En d'autres termes, les différents systèmes numériques ont leurs propres fractions infinies. Par conséquent, une fraction non infinie en décimal peut être un en binaire. Par exemple : 0,1, 0,2, 0,3, 0,4, ... n'ont pas de représentation binaire exacte. Si vous appelez NormalizeDouble dix fois, il sera soit 0.19999999999...1 soit 0.200000...1. Je ne sais pas, c'est peut-être une nouvelle.

Tu dis la vérité ! Pour être clair, le ND est nécessaire UNIQUEMENT pour la comparaison, pas pour la représentation. Et c'est obsolète depuis longtemps.

 
pavlick_:
Certains nombres ne peuvent être représentés que par des fractions infinies, par exemple 1/3 dans le système décimal. Mais 1/3 n'est pas une fraction infinie dans le système tertiaire, là il == 0,1. En d'autres termes, les différents systèmes numériques ont leurs propres fractions infinies. Ainsi, une fraction non infinie en décimal peut être égale à un en binaire. Par exemple : 0,1, 0,2, 0,3, 0,4, ... n'ont pas de représentation binaire exacte. Si vous appelez NormalizeDouble dix fois, il sera soit 0,1999999999999...1 soit 0,200000...1. Je ne sais pas, c'est peut-être une nouvelle.

Je m'en souviens, mais dans ce cas, c'est 0+0 et ce n'est pas 0.

 
transcendreamer:

Je m'en souviens, mais dans ce cas, c'est 0+0 et ce n'est pas 0.

Dans quel cas ? Donnez-moi un exemple de cas où c'est le cas.
 
fxsaber:

Tu dis la vérité ! Pour être clair, le ND est nécessaire UNIQUEMENT pour la comparaison, pas pour la représentation. Et est depuis longtemps obsolète.

NormalizeDouble est uniquement nécessaire pour normaliser le prix lors du placement d'ordres en attente et de stops. Il n'en a pas besoin pour autre chose.

Ceci est clairement indiqué dans la documentation

Les valeurs calculées de StopLoss et TakeProfit, ainsi que les prix ouverts des ordres en attente, doivent être normalisés avec la précision, dont la valeur peut être obtenue par Digits().

 
Sergei Vladimirov:
Dans quel cas particulier ? Donnez-moi un exemple où cela se produit.

cela se produit lorsqu'il y avait 0 dans la variable et que 0 y est ajouté

(Je soupçonne que ce n'est pas vraiment 0)

 
Slawa:

NormalizeDouble est uniquement nécessaire pour normaliser le prix lors du placement d'ordres en attente et de stops. Il n'en a pas besoin pour autre chose.

Ceci est clairement indiqué dans la documentation

Mais qu'en est-il de la comparaison des chiffres réels...
 
transcendreamer:

cela se produit lorsqu'il y avait 0 dans la variable et que 0 y est ajouté

(Je soupçonne que ce n'est pas vraiment 0)


Exactement. Les "vrais" zéros de l'addition et de la soustraction restent des zéros. C'est pourquoi je vous ai proposé un exemple.

 
Alexander Bereznyak:
Et si on comparait les chiffres réels...

Un effet secondaire connexe.

Ça s'est avéré 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 le nombre réel avec la bonne précision.

Dites-moi, pourquoi avez-vous besoin d'arrondir les nombres réels dans les calculs ? Car dans ce cas, la précision des calculs est perdue !

 
Sergei Vladimirov:

Exactement. Les "vrais" zéros dans l'addition et la soustraction sont toujours des zéros. C'est pourquoi je vous ai proposé un exemple.

Je commençais à penser queNormalizeDouble(new_lot-sum_lots,Lots_Digits) ; ne produit pas exactement 0 et stocke un peu de queue.
 
Slawa:

NormalizeDouble est uniquement nécessaire pour normaliser le prix lors du placement d'ordres en attente et de stops. Il n'en a pas besoin pour autre chose.

Ceci est clairement indiqué dans la documentation

Obsolète

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Implémentations alternatives de fonctions/approches standard

Renat Fatkhullin, 2016.09.02 00:55

Ce n'est pas une façon de surcharger. Mêmes signatures de fonctions.

Mais l'idée est claire - la fonction de normalisation tenant compte de la granulation des tiques.