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
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.
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.
Je m'en souviens, mais dans ce cas, c'est 0+0 et ce n'est pas 0.
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().
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)
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
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.
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 !
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.
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
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.