算术比较以避免浮点错误

Question

I have the following check in one of my Java functions...

return floor(value * 100.) % 5 == 0;

I've been told that there is a potential for floating point errors because I am comparing raw values using == but I cannot see why. I thought that using floor would avoid that. Why might there be a floating point error and what is the best practice in this case to avoid such errors?

Answer 1

Why might there be a floating point error…

There are three potential places for floating-point error in the expression you show:

• value is presumably the result of prior computations, and those might have had errors. We have no information about those, since you have not shown them.
• The code suggests there is some interest in value as some number of hundredths: .01, .02, .03, and so on. Except for .00, .25, .50, and .75, no hundredths are representable in the binary floating-point format Java uses. So, even if prior computations were done as accurately as possible, the final result cannot possibly equal any number of hundredths other than .00, .25, .50, or .75. They will be at least slightly higher or lower. If they are lower, then multiplying by 100 and taking the floor may produce a value one lower than you desire.
• When value is multiplied by 100, if the result is not exactly representable (which it may not be because value may have 53 significant bits and 100 has 5 significant bits, so the product may have 58 significant bits, but only 53 can be represented in Java's double format), then it is rounded to the nearest representable value.

Floating-point arithmetic is largely designed to approximate real arithmetic. For this purpose, it is generally good with continuous functions, such as multiplication, sine, and so on. Often, with continuous functions small errors in calculation produce small errors in results. However, floor , % , and == are discontinuous functions: They have places where some changes in the inputs cause jumps in the outputs. For floor, a small change from 3.99 to 4 causes a jump of 1 in the output. For % , a small change from 3.99 % 4 to 4 % 4 causes a jump of nearly 4. For == , a small change from 3.99 == 4 to 4 == 4 causes a jump from false to true .

… what is the best practice in this case to avoid such errors?

By and large, the best practice when you need exact results for computations involving % is to use integer arithmetic or to use floating-point with care to ensure all operations are exact (as by doing integer arithmetic within the bounds where floating-point represents all integers, −2 ⁵³ to +2 ⁵³ for Java double ). If you need to work around that, then there is no single best practice; good solutions would depend on what you are doing to obtain value and what results you are trying to achieve.

Answer 2

I think that's a mistake we (Java developers) often make, but in general it can be observed in almost all programming languages — at least the ones I use these days.

The entire thing boils down to how those values are stored in memory — if I'm not mistaken, in Java, float s and double s are stored using the IEEE 754 standard format.

Anyway, instead of using the equality operator ( == ), we should rely on relational operators: less than ( < ) or greater than ( > ) to compare float and double values, because in the end, floating point numbers are just an approximation , they are not exact.

Another approach (I personally like) is to use Float.compare / Double.compare , if you are more familiar with the semantics of compareTo -kind of comparisons.

Alternatively, I sometimes use also BigDecimal for exact calculations.