Java double comparaison epsilon

Question

J'ai écrit une classe qui teste l'égalité, inférieure à, et supérieure à deux doubles en Java. Mon cas général est la comparaison des prix qui peuvent avoir une précision d'un demi-cent. 59.005 contre 59.395. L'epsilon que j'ai choisi est-il adéquat pour ces cas?

private final static double EPSILON = 0.00001; 


/** 
* Returns true if two doubles are considered equal. Tests if the absolute 
* difference between two doubles has a difference less then .00001. This 
* should be fine when comparing prices, because prices have a precision of 
* .001. 
* 
* @param a double to compare. 
* @param b double to compare. 
* @return true true if two doubles are considered equal. 
*/ 
public static boolean equals(double a, double b){ 
    return a == b ? true : Math.abs(a - b) < EPSILON; 
} 


/** 
* Returns true if two doubles are considered equal. Tests if the absolute 
* difference between the two doubles has a difference less then a given 
* double (epsilon). Determining the given epsilon is highly dependant on the 
* precision of the doubles that are being compared. 
* 
* @param a double to compare. 
* @param b double to compare 
* @param epsilon double which is compared to the absolute difference of two 
* doubles to determine if they are equal. 
* @return true if a is considered equal to b. 
*/ 
public static boolean equals(double a, double b, double epsilon){ 
    return a == b ? true : Math.abs(a - b) < epsilon; 
} 


/** 
* Returns true if the first double is considered greater than the second 
* double. Test if the difference of first minus second is greater then 
* .00001. This should be fine when comparing prices, because prices have a 
* precision of .001. 
* 
* @param a first double 
* @param b second double 
* @return true if the first double is considered greater than the second 
*    double 
*/ 
public static boolean greaterThan(double a, double b){ 
    return greaterThan(a, b, EPSILON); 
} 


/** 
* Returns true if the first double is considered greater than the second 
* double. Test if the difference of first minus second is greater then 
* a given double (epsilon). Determining the given epsilon is highly 
* dependant on the precision of the doubles that are being compared. 
* 
* @param a first double 
* @param b second double 
* @return true if the first double is considered greater than the second 
*    double 
*/ 
public static boolean greaterThan(double a, double b, double epsilon){ 
    return a - b > epsilon; 
} 


/** 
* Returns true if the first double is considered less than the second 
* double. Test if the difference of second minus first is greater then 
* .00001. This should be fine when comparing prices, because prices have a 
* precision of .001. 
* 
* @param a first double 
* @param b second double 
* @return true if the first double is considered less than the second 
*    double 
*/ 
public static boolean lessThan(double a, double b){ 
    return lessThan(a, b, EPSILON); 
} 


/** 
* Returns true if the first double is considered less than the second 
* double. Test if the difference of second minus first is greater then 
* a given double (epsilon). Determining the given epsilon is highly 
* dependant on the precision of the doubles that are being compared. 
* 
* @param a first double 
* @param b second double 
* @return true if the first double is considered less than the second 
*    double 
*/ 
public static boolean lessThan(double a, double b, double epsilon){ 
    return b - a > epsilon; 
} 

Answer 1

Oui. Les doubles Java tiendront leur précision mieux que votre epsilon donné de 0.00001.

Toute erreur d'arrondi qui se produit en raison du stockage des valeurs en virgule flottante se produira plus petit que 0,00001. J'utilise régulièrement 1E-6 ou 0.000001 pour un double epsilon en Java sans problème. Sur une note connexe, j'aime le format de epsilon = 1E-5; parce que je pense qu'il est plus lisible (1E-5 en Java = 1 x 10^-5). 1E-6 est facile à distinguer de 1E-5 lors de la lecture du code alors que 0.00001 et 0.000001 ont l'air si similaires en regardant le code que je pense qu'ils ont la même valeur.

Answer 2

Whoa whoa whoa. Y a-t-il une raison spécifique pour laquelle vous utilisez le flottant pour la devise, ou est-ce que les choses seraient mieux avec un arbitrary-precision, fixed-point number format? Je n'ai aucune idée de ce que le problème que vous essayez de résoudre est, mais vous devriez penser si un demi-cent est vraiment quelque chose que vous voulez travailler, ou si c'est juste un artefact d'utiliser un format numérique imprécis.

Answer 3

Vous n'utilisez PAS le double pour représenter de l'argent. Jamais. Utilisez java.math.BigDecimal à la place.

Ensuite, vous pouvez spécifier exactement comment arrondir (ce qui est parfois dicté par la loi dans les applications financières!) Et ne pas avoir à faire des hacks stupides comme ce truc epsilon. Sérieusement, l'utilisation de types à virgule flottante pour représenter l'argent est extrêmement peu professionnelle.

Answer 4

Les nombres à virgule flottante ont seulement autant de chiffres significatifs, mais ils peuvent aller beaucoup plus haut. Si votre application traite un grand nombre, vous remarquerez que la valeur epsilon doit être différente.

0,001 + 0,001 = 0,002 MAIS 12.345.678.900.000.000.000.000 + 1 = 12.345.678.900.000.000.000.000 si vous utilisez à virgule flottante et double. Ce n'est pas une bonne représentation de l'argent, à moins que vous soyez sacrément sûr de ne jamais gérer plus d'un million de dollars dans ce système.

Answer 5

Cents? Si vous calculez des valeurs monétaires, vous ne devriez pas utiliser de valeurs flottantes. L'argent est en fait des valeurs dénombrables. Les centimes ou centimes, etc. peuvent être considérés comme les deux (ou n'importe quels) chiffres les moins significatifs d'un nombre entier. Vous pouvez stocker et calculer des valeurs monétaires sous la forme d'entiers et diviser par 100 (par exemple placer un point ou une virgule deux avant les deux derniers chiffres). L'utilisation de flotteur peut conduire à des erreurs d'arrondi étranges ...

Quoi qu'il en soit, si votre epsilon est censé définir la précision, il semble un peu trop petit (trop précis) ...

Answer 6

Si vous faites affaire avec de l'argent Je suggère de vérifier le modèle de conception de Money (à l'origine de Martin Fowler's book on enterprise architectural design).

Je vous suggère de lire ce lien pour la motivation: http://wiki.moredesignpatterns.com/space/Value+Object+Motivation+v2

Answer 7

Bien que je suis d'accord avec l'idée que le double est mauvais pour l'argent, toujours l'idée de comparer double a un intérêt. En particulier, l'utilisation suggérée d'epsilon est seulement adaptée aux nombres dans une gamme spécifique.Voici une utilisation plus générale d'un epsilon, par rapport au rapport des deux nombres (test pour 0 omis):

booléen égal (double d1, double d2) { double d = d1/d2; return (Math.abs (d-1,0),001); }

Answer 8

Si vous pouvez utiliser BigDecimal, utilisez-le, sinon:

/** 
    *@param precision number of decimal digits 
    */ 
public static boolean areEqualDouble(double a, double b, int precision) { 
    return Math.abs(a - b) <= Math.pow(10, -precision); 
} 

Answer 9

Comme d'autres commentateurs correctement noté, vous devriez jamais utiliser l'arithmétique à virgule flottante lorsque les valeurs exactes sont requises, telles que pour valeurs monétaires. La raison principale est en effet le comportement d'arrondi inhérent aux points flottants, mais n'oublions pas que traiter avec des points flottants signifie aussi avoir à faire face à des valeurs infinies et NaN.

Pour illustrer que votre approche ne fonctionne tout simplement pas, voici un code de test simple. J'ajoute simplement votre EPSILON à 10.0 et regarder si le résultat est égal à 10.0 - qui ne devrait pas être, comme la différence est clairement pas moins que EPSILON:

double a = 10.0; 
    double b = 10.0 + EPSILON; 
    if (!equals(a, b)) { 
     System.out.println("OK: " + a + " != " + b); 
    } else { 
     System.out.println("ERROR: " + a + " == " + b); 
    } 

Surprise:

ERROR: 10.0 == 10.00001 

Les erreurs se produisent en raison de la perte si des bits significatifs sur la soustraction si deux valeurs à virgule flottante ont des exposants différents.

Si vous pensez à appliquer une approche « différence relative » plus avancée comme suggéré par d'autres commentateurs, vous devriez lire l'excellent article de Bruce Dawson Comparing Floating Point Numbers, 2012 Edition, ce qui montre que cette approche a des lacunes similaires et qu'il n'y a en fait pas FAIL comparaison approximative sans danger à virgule flottante qui fonctionne pour toutes les plages de nombres à virgule flottante.

Pour faire court: s'abstenir de double s pour les valeurs monétaires, et utiliser des représentations exactes des nombres telles que BigDecimal. Par souci d'efficacité, vous pouvez également utiliser longs interprété comme "millis" (dixièmes de centimes), tant que vous évitez de manière fiable les dépassements et les sous-flux. Cela donne un maximum de valeurs représentables de 9'223'372'036'854'775.807, ce qui devrait être suffisant pour la plupart des applications du monde réel.