LMAX Exchange
Of all the data types, double is probably one of the most
misunderstood. A huge amount of folk lore has been built up around it to
help protect developers from falling into its many pitfalls.
Lately I’ve done a lot of work replacing usage of BigDecimal with
double and learnt a lot about where those pitfalls are and how the folk
lore can be misleading.
The great challenge with double is that it
has a degree of inaccuracy because of the way the number is actually
stored. For example, the number 2983792734924.2293 actually
winds up being stored as 2983792734924.2295, a tiny difference but
with far reaching consequences. All of the folk lore around doubles is
designed to deal with this potential for inaccuracy.
One piece of
folk lore is that you should never do a strict comparison of double
values (e.g. with == or !=). Due to the inaccuracy of doubles you
should always compare them with a level of tolerance:
abs(doubleA - doubleB) < tolerance
It’s
important to realise however, that this inaccuracy isn’t random, it’s
perfectly consistent and predictable. The
number 2983792734924.2293 always comes out
as 2983792734924.2295. The same applies if you parse it from a
string: parseDouble(“2983792734924.2293″) always comes out as 2983792734924.2295. As a result the following are consistently true:
2983792734924.2293 == 2983792734924.2293
parseDouble("2983792734924.2293") == 2983792734924.2293
parseDouble("2983792734924.2293") == parseDouble("2983792734924.2293")
Introducing
tolerance to the comparison can lead to subtle bugs. For example, if we
were updating our model with user input we might have something like:
// In our model:
public void setAmount(double amount) {
this.amount = amount;
fireChangeEvent();
}
// In our UI code:
model.setAmount(parseDouble(widget.getText()));
So far so good,
but what if we want to avoid firing the change event if the value hadn’t
really changed? We might change the model code to:
public void setAmount(double amount) {
if (abs(amount - this.amount) > 0.01) {
this.amount = amount;
fireChangeEvent();
}
}
It follows the double folk lore, but also introduces a
bug. Let’s say the user first enters the amount ’1′. Then they
change the amount to ’1.001′. The second amount is within the
tolerance so it’s not considered an actual change. The user is now
looking at a text field that says 1.0001, but the model thinks the value
is still 1. You can make the tolerance smaller but that just
means the user has to enter more zeros to trigger the problem.
The
right answer is to take advantage of the fact that inaccuracy with
doubles is consistent and do the comparison using strict comparison:
public void setAmount(double amount) {
if (about != this.amount) {
this.amount = amount;
fireChangeEvent();
}
}
So when doesn’t this work? When the two values are calculated in different ways. So:
(1491896367462.1147 * 29.837927349242293) / 2.3982983923 = 18561116318075.207 1491896367462.1147 * (29.837927349242293 / 2.3982983923) = 18561116318075.203
The only difference between the two equations is the order of evaluation they should
give the same answer, but because doubles have a degree of inaccuracy
the intermediate result is rounded to something that will fit in a
double, so the order of evaluation matters because it affects what
rounding is done to the intermediate result. Repeating the exact same
calculation will always give the exact same result, but if there’s any
chance that the values were calculated in different ways, comparisons
must be done with tolerance.
So the folk lore about needing to
compare doubles with some tolerance is perfectly valid, good advice, but
be aware that it introduces its own inaccuracy which may cause
problems. You should consider what the impact of falsely deciding that
the values are different vs falsely deciding that the values are the
same; which side should you err on?
Sometimes you really do want a strict comparison, even between doubles.