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
Si c'est pour la comparaison, vous pourriez facilement créer votre propre fonction :
C'est juste une idée.
Si c'est pour la comparaison, vous pourriez facilement créer votre propre fonction :
C'est juste une idée.
C'est une bonne idée, je vous en remercie :-)
L'utilisation de "Point" ou "Point/2.0" n'est pas une très bonne valeur de différence, IMO. L'erreur d'arrondi introduite par NormalizeDouble (qui m'a brûlé aujourd'hui), est certainement beaucoup plus petite que 8 chiffres, plus probablement 15 chiffres.
Compte tenu des conseils précédents, j'ai apporté quelques modifications et mis au point la routine suivante qui semble fonctionner correctement (même en utilisant la "différence" à 15 décimales), bien qu'elle n'ait pas encore été rigoureusement testée :
Here is a check of the obvious:
Voici encore une autre routine possible qui peut comparer, mais qui peut aussi normaliser en interne soit A et/ou B, et qui va aussi relaxer la différence de comparaison (de A-B ou B-A) à un nombre plus grand basé sur les "chiffres". Je doute que cette routine soit nécessaire par rapport à la simple "AvsB" ci-dessus, mais elle est proposée à votre usage si vous le souhaitez :
L'utilisation de "Point" ou "Point/2.0" n'est pas une très bonne valeur de différence, IMO. L'erreur d'arrondi introduite par NormalizeDouble (qui m'a brûlé aujourd'hui), est certainement beaucoup plus petite que 8 chiffres, plus probablement 15 chiffres.
Vous voulez la plus grande valeur qui ne peut pas être considérée comme une erreur d'arrondi ou, de manière équivalente, la plus petite valeur qui ne peut pas être considérée comme un changement de prix. Puisque les prix ne peuvent changer que d'un multiple de point, point/2 est exactement cela.
La valeur double du courtier pourrait être n'importe où entre 1,23457500000000 et 1,23458499999999999 et être toujours considérée comme le même prix de 1,23458.
Si vous aviez utilisé cette méthode, vous n'auriez pas eu ce problème :
if (a > b)
if (a >= b)
if (a != b)
Devons-nous éviter d'utiliser la fonction normalisedouble ?
ou peut-être... j'ai pensé que nous pouvons utiliser lafonction MathRound
ex . double x= (MathRound( 1.37883 * 100000)) / 100000 ;
Ainsi, nous pouvons créer la fonction
*N'utilisez NormalizeDouble que dans les calculs impliquant une valeur double et non pas partout où il y a un double.
Devons-nous éviter d'utiliser la fonction normalisedouble ?
ou peut-être... j'ai pensé que nous pourrions utiliser la fonction MathRound
ex . double x= (MathRound( 1.37883 * 100000)) / 100000 ;
Vous vous retrouvez quand même avec un double et toujours la possibilité de prix != prix
Je suis arrivé à cette solution qui transforme les doubles en ints dans le but de comparer les doubles . . .
de sorte que...
ne sera jamais vrai.