21

What is the best way to explain floating point rounding issue to customers?

I know

http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html

as well as the entries in the C++ FAQ and various other pages aimed at developers and scientists, but is there a web page, article or explanation, aimed at "regular" customers with limited mathematical or scientific background? (for which the above references fall flat).

If it were maintained or coming from a well-known and well-recognized institution or corporation, all the better, given that, as some of you might have experienced, it can be a little complicated to explain that yourself.

mouviciel
  • 15,491

8 Answers8

7

I find a simple way to explain this is to demonstrate it. Discuss how dividing x by a number, then multiplying by the same number should return you to x again - get the customer to agree that this should always be the case. Then do the old (100 / 3) * 3 on a calculator; show that the value doesn't, as you would expect, return to 100. When most people see apparently simple maths "breaking down", then tend to 'get' the danger of floating point numbers where accuracy is important (although in an intuitive way, rather than to the low level the article you point to goes into).

Unfortunately most half-decent calculators (certainly all the scientific ones I've seen, and more than a few basic ones) nowadays are able to handle this - I presume they're storing extra digits beyond what can be displayed and rounding - so do check how clever your calculator is before you do it in front of your customer.

Scott
  • 2,081
5

I don't think there are shortcuts. You have to either:

  • Understand what floating point is and how it behaves.

Or, if that's too much required, the you have to just:

  • Accept that the computer won't give you exact numeric results.

Maybe an example with irrational numbers helps (even though floating point issues apply to rational numbers as well): sqrt(2) ~ 1.414. Then 1.414^2 = 1.999396. No matter how many digits you take, you'll never get quite back to the original 2. Ok, 4 significant digits correct may be acceptable, but then consider what happens when this kind of "rounding errors" accumulate. That's where the real danger is.

5

First, determine what they're complaining about. Financial transactions have to be done precisely, with the right number of decimal places and the right rounding rules. This typically means maintaining integral numbers of currency units and making sure the arithmetic is done right.

Alternatively, they may be complaining about overexact displays, and reducing the number of significant digits output may be all that's necessary.

For numbers in general, you can always try to come up with a three-digit decimal x such that x * 3 is 10. That shows the basic principles.

There are two remaining problems. One is that certain numbers can be expressed exactly in decimal but not binary (3.15, say). That's going to be hard to explain to non-technical people, and your best bet is to try to avoid it by not providing enough significant digits for it to show up. The other is the customer who knows a little bit, enough to know that computer arithmetic isn't always exact and not enough to realize that decimal arithmetic isn't always exact. I have argued with a few of those, and have nothing useful to report.

2

Floating point numbers in computers use binary, so just like we have a number system with a ones, tens, hundreds, and tenths, hundredths columns, floating point numbers in computers actually have a ones, twos, fours, and halves, quarters, and eighths columns. If the customer is familiar with feet/inches, then remind them of how you typically use base-2 fractions of an inch for measurement.

Now try to store 10 cents as a combination of halves, quarters, eighths of a dollar. It just doesn't work:

.00011001100110011 . . . (repeats infinitely)

It's the same as taking a standard imperial measuring tape and trying to measure one tenth of an inch. You can't do it accurately. There is no representation of 1/10 as X/Y where X and Y are whole numbers and Y is a power of 2.

That's why we have the decimal data types that use 4 bits to store each decimal digit, so we're back to base 10 representation. The trade-off is in space and performance (about a 100% performance hit, from what I've read).

1

2/3

Ask them to write down the exact answer to two divided by 3.
Since the answer 'goes on for forever' you can point that out.

Using 1/3 would also work but 2/3 is perhaps a slightly better example as rounding gives you (e.g.) .6666667 whereas .3333333 looks like it can just be truncated.

1

Tell them that just like their bank account cannot hold 4.4423425908459032890413... dollars (it's either $4.44 or $4.45, nothing in between), the computer cannot easily store a number with arbitrary precision. Imperfections of storage lead to imperfections of computations.

(It's slightly cheating, but should give them an idea of what the problem is.)

quant_dev
  • 5,227
0

Some calculations are done according to some legal rule. For example, if you want to calculate how much income tax has to be paid on a taxable annual income of €79.245,18 in Germany, there is only one correct answer. You get it right or you get it wrong. If you get it right, you don't need to explain how floating point arithmetic works. If you get it wrong, you don't need to explain how floating point arithmetic works, you have to fix your broken code.

Sometimes you display results that don't look right. For example, if you convert US$ 13,297.46 into UK£ with two decimal digits, and then convert that amount of UK£ back to US$, you might not get US$ 13,297.46 but US$ 13,297.45 or US$ 13,297.47. That has nothing to do with floating-point arithmetic. It's an unavoidable problem and you better be able to explain why it is unavoidable. (You should also know why the problem doesn't happen when you convert from UK£ to US$ and back).

There are other possible results that don't look right. If you convert numbers to percentages the percentages should add up to 100%, but they might not. If you display four percentages with two decimals, the four displayed percentages might add up to 99.99% or 100.01%. Nothing to do with floating-point arithmetic. Still you should be able to explain why.

Next, there are situations where careless use of floating-point arithmetic leads to inappropriate results. For example, a + b + c is usually not the same as b + c + a. If that causes a problem, there is nothing to explain, it's something that you fix.

gnasher729
  • 49,096
0

When doing calculations computers usually use approximations to numbers (like rather than using 1000000.7 they use 1000000) because using approximations is much faster. The problem with that is that when you do calculations with approximations you get approximations back. Usually that works pretty well, but sometimes it leads to unexpected results.