public final class DecimalComparison
extends java.lang.Object
| Modifier and Type | Field and Description |
|---|---|
static double |
DOUBLE_EPSILON
The value used for double comparison.
|
static float |
FLOAT_EPSILON
The value used for float comparison.
|
| Modifier and Type | Method and Description |
|---|---|
static boolean |
equals(double a,
double b)
Tests for equality of double values using
DOUBLE_EPSILON. |
static boolean |
equals(double a,
double b,
double epsilon)
Tests for double equality using a custom epsilon value.
|
static boolean |
equals(float a,
float b)
Tests for equality of float values using
FLOAT_EPSILON. |
static boolean |
equals(float a,
float b,
float epsilon)
Tests for float equality using a custom epsilon value.
|
static int |
hash(double d)
Takes the hash code of doubles.
|
public static final double DOUBLE_EPSILON
public static final float FLOAT_EPSILON
public static final boolean equals(double a,
double b)
DOUBLE_EPSILON.
WARNING: this method is not technically transitive. If a and b are off by slightly less than
epsilon * max(abs(a), abs(b)), and b and c are off by slightly less than
epsilon * max(abs(b), abs(c)), then equals(a, b) and equals(b, c) will both return true, but equals(a, c)
will return false. However, this situation is very unlikely to ever happen in a real programming situation.
If this does become a concern, some ways to solve this problem:
equals(double, double, double) (this does not make a violation of
transitivity impossible, it just significantly reduces the chances of it happening)
BigDecimal instead of double (this will make a violation of transitivity 100% impossible)
a - first value to testb - second value to test#hashCode(double)public static final boolean equals(double a,
double b,
double epsilon)
WARNING: this method is not technically transitive. If a and b are off by slightly less than
epsilon * max(abs(a), abs(b)), and b and c are off by slightly less than
epsilon * max(abs(b), abs(c)), then equals(a, b) and equals(b, c) will both return true, but equals(a, c)
will return false. However, this situation is very unlikely to ever happen in a real programming situation.
If this does become a concern, some ways to solve this problem:
BigDecimal instead of double (this will make a violation of transitivity 100% impossible)
a - first value to testb - second value to testepsilon - allowed differencepublic static final boolean equals(float a,
float b)
FLOAT_EPSILON.
WARNING: this method is not technically transitive. If a and b are off by slightly less than
epsilon * max(abs(a), abs(b)), and b and c are off by slightly less than
epsilon * max(abs(b), abs(c)), then equals(a, b) and equals(b, c) will both return true, but equals(a, c)
will return false. However, this situation is very unlikely to ever happen in a real programming situation.
If this does become a concern, some ways to solve this problem:
equals(float, float, float) (this does not make a violation of
transitivity impossible, it just significantly reduces the chances of it happening)
BigDecimal instead of float (this will make a violation of transitivity 100% impossible)
a - first value to testb - second value to testpublic static final boolean equals(float a,
float b,
float epsilon)
WARNING: this method is not technically transitive. If a and b are off by slightly less than
epsilon * max(abs(a), abs(b)), and b and c are off by slightly less than
epsilon * max(abs(b), abs(c)), then equals(a, b) and equals(b, c) will both return true, but equals(a, c)
will return false. However, this situation is very unlikely to ever happen in a real programming situation.
If this does become a concern, some ways to solve this problem:
BigDecimal instead of float (this will make a violation of transitivity 100% impossible)
a - first value to testb - second value to testepsilon - allowed differencepublic static final int hash(double d)
equals(double, double) will have the
same hash code.d - double to hash