Hi. > > > > > This message is about some methods in Precision class, and follows a > > discussion about MATH-863 > > (https://issues.apache.org/jira/browse/MATH-863). > > > > Recently, we slightly modified our Precision class, by adding a > > specific epsilon value to compute a relative deviation and also some > > methods. --- /** Epsilon used for doubles relative comparison */ > > public static final double DOUBLE_COMPARISON_EPSILON = 1.0e-14; --- > > > > This value is quite useful to compare two values. It's > > approximatively 100 times larger than the previous EPSILON value > > (1e-16, the difference between 1. and the next closest value). > > > > We also added static methods, to compute a relative difference : if > > x1 and x2 are not equal (according to the equals(x1,x2, "1 ulp") > > function), then we compute a relative deviation > > ("abs(x1-x2)/max(abs(x1),abs(x2))" and see if it's lower than an > > epsilon value. > > The comparison should probably rather be: > abs(x1-x2) <= eps * max(abs(x1),abs(x2) > > The reason for that is that with your implementation when both x1 and x2 > are 0 (either +0 or -0), then the result would be false, despite the > numbers are equal. The division 0/0 leads to a NaN and all comparisons > involving NaN return false.
Unfotunately, that version makes the comparison fail when one of the argument is infinite; in that case we get for the proposed code inf / inf < eps --> false thanks to NaN while the above leads to inf <= inf --> true Also, the proposed implementation first checks for strict equality: when the arguments are equal, the division is not performed. [I wanted to replace the proposed implementation with a call to the existing "absolute" comparison method, but because of that problem, it doesn't seem possible without adding conditionals.] > > > > --- public static boolean equalsWithRelativeTolerance(final double x, > > final double y) -> uses the DOUBLE_COMPARISON_EPSILON public static > > boolean equalsWithRelativeTolerance(final double x, final double y, > > final double eps) --- > > > > These kind of methods are used in some of our tools (space dynamic > > libraries) to assert equality between values, when we don't know the > > order of magnitude. > > > > Do you think it's useful for Commons Math users ? Shall I open a > > ticket on JIRA and contribute the corresponding code source ? > > Yes, along with test cases, including special cases (+/-0, +/-infinity, > NaNs, +/-Double.MAX_VALUE, +/-Double.MIN_VALUE ...) I think that we should focus on the second version (with an explicit tolerance). The tolerance is very much case-dependent, so that the default value is not widely useful: Why 1e-14 rather than 1e-15 or 1e-13 or even 1e-7 ? Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
