https://issues.apache.org/bugzilla/show_bug.cgi?id=50033
Yegor Kozlov <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from Yegor Kozlov <[email protected]> 2010-10-01 08:04:02 EDT --- Thanks for the patch, applied in r1003504 The fact that in some cases the results are slightly 'off' is normal, it is the way floating-point arithmetic works. In particular, the value of 1.4 cannot be represented as an exact value, on low-level it is a result of a truncated series. A way to check it is via BigDecimal(1.4).toString() which returns 3.399999999999999911182158029987476766109466552734375. A smarter version of MathX.mod might use BigDecimal for calculations: public static double mod(double n, double d) { BigDecimal number = new BigDecimal(n); BigDecimal divisor = new BigDecimal(d); double result; if (d == 0) { result = Double.NaN; } else if (sign(n) == sign(d)) { result = number.remainder(divisor).doubleValue(); } else { result = number.remainder(divisor).add(divisor).remainder(divisor).doubleValue(); } return result; } In the case of MathX.mode this seems OK, but I'm reluctant to make this change. Using BigDecimal for calculations should be project-wide. Regards, Yegor -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
