A bug has been found in Excel 2007 and Excel services 2007 which appears to calculate certain results incorrectly. In fact, the stored value of the result is correct, and other calculations based on that result will calculate correctly. The only error is in the display of the number, not the internal calculation. This is, of course, still a problem for anyone who is reading the values on screen or on a printout, or exporting them to other programs (see further down in this post).
According to the article on the Excel team blog about this bug:
The first example that we heard about was =77.1*850, but it became clear from our testing as well as additional reports that this was just one instance where Excel 2007 would return a value of 100,000 instead of 65,535. The majority of these additional reports were focused on multiplication (ex. =5.1*12850; =10.2*6425; =20.4*3212.5 ), but our testing showed that this really didn’t have anything do to with multiplication – it manifested itself with many but not all calculations in Excel that should have resulted in 65,535 (=65535*1 and =16383.75*4 worked for instance). Further testing showed a similar phenomenon with 65,536 as well. This issue only exists in Excel 2007, not previous versions.
…
Said another way, =850*77.1 will display an incorrect value, but if you then multiply the result by 2, you will get the correct answer (i.e. if A1 contains “=850*77.1”, and A2 contains “=A1*2”, A2 will return the correct answer of 131,070).
So, it is important to note that most calculations which result in numbers near to or equal to 65,535 and 65,536 will be absolutely fine. It is only through some very specific oddities about how floating point numbers work that you will get one of the 12 situations where this bug occurs. If it does, you will have cells that read “100,000″ rather than the correct answer. Anything else in Excel which you base on those cells will be correct.
You can add to them, multiply by them, show conditional formats such as colour scales or icon sets, even draw charts with those values and Excel will correctly handle the real, underlying value and not the displayed one. Macros or external programmatic methods of retrieving the cell’s contents also return the true stored value.
When does this actually give you the wrong values (rather than just a wrong display)?
Rounding the result will change to the incorrect value permanently
Some people find it confusing that when they have a column of figures added up, the sum at the bottom may not seem to be correct.
A typical example would be a column of prices including added sales tax (by multiplying by some decimal factor). These prices will only be shown to two decimal places in most currencies, but there will be a bit of rounding up or down to achieve this.
The sum of the underlying values may therefore differ from a sum of the displayed values, which gives the impression that there is a miscalculation somewhere, as shown in the example to the right. One way to avoid this is to use one of the ROUND functions to actually ROUND off the stored value to the nearest 1/100th (or force it to always ROUNDUP or ROUNDDOWN). The advantage of this is that if you change your mind you can easily change the formula to increase or decrease the accuracy of the underlying numbers, and my own recommendation would usually be to use this method.
If you ROUND a cell or calculation which has a buggy result you will get the wrong value as a fixed end result.
So, 2 * ROUND(850 * 77.1, 0) gives 200,000 as a result, whereas 2 * 850 * 77.1 gives the correct 131,070. This is true whether you use ROUND directly on a buggy calculation or on a cell containing the end result of one. Curiously, ROUNDUP and ROUNDDOWN are able to ignore the bug, and both ROUNDDOWN(850 * 77.1, 0) and ROUNDUP(850 * 77.1, 0) correctly result in 65,535 (since this is what the value “actually” is if you ignore floating point errors).
Telling Excel to use precision as displayed will keep the wrong value.
The alternative to the ROUND function to get over sums which appear inconsistent is to change one of your Excel options to “Set precision as displayed”. This means that if you change the number of decimal places shown in a cell (using the toolbar buttons or changing the number formatting) the actual stored value will change immediately and permanently to be rounded to that many decimal places. If you decrease the decimals to zero, then increase them again, all your numbers will be .0000… Of course, if the cell contains the result of a formula, you lose nothing, but if it contains data values they will be irrevocably changed. The point of this feature is to save you using those ROUND functions, and to make sure that what you see always appears to be calculated consistently.
It is set on a per-workbook basis, so it is perfectly possible for you to receive a workbook which already has this turned on. By the same token, if you use this feature you may actually confuse someone else who works on that same workbook, or they may permanently lose data accuracy by changing the formatting of cells if they are not aware that this is taking place.
In order to be able to see if it is turned on or not, and change it if you wish, in Excel 2007 go to the Office button at the top left, choose Excel options, then the advance section and look for the subsection labelled “When calculating this workbook” where you will find “Set precision as displayed” (as shown on the left).
For Excel 2003 the same option is in Tools > Options > Calculation under Workbook options and called simply “precision as displayed”. NOTE: the bug described in this post does not affect Excel 2003, the way to turn on or off this feature is only included here for completeness since the state of the feature is saved with the workbook, not as part of your Excel options.
If you have this feature turned on and your workbook contains calculation which have this bug, then those results will become permanently wrong (as 100,000 or 100,001). Any other calculations based on those cells will also be incorrect. Unless you can be sure to check every single cell in a workbook, which is only practical for very small files, you really need to turn this feature off when using Excel 2007 until a fix for the bug is applied.
Exporting incorrect values
As long as you handle the numbers within Excel, they work properly and simply display incorrectly. However, if you copy cells with these incorrect values and paste out to a text editor (such as Notepad), the incorrect display value is carried, because this always passes the number as shown, rather than the internal value. If you are only showing figures rounded to two decimal places (but not actually ROUNDing them) then Notepad would show the same as the sheet, and the underlying extra accuracy is lost.
While Notepad is useful to quickly see these bugs in action, it is not usually used as an import and export routine for large volumes of multi-column data. A common method is to export to a CSV file which can then be imported into another program (often a database which cannot read and write to Excel files directly). CSV files will also carry the incorrect display figure instead of the underlying stored value. This is crucial for anyone using Excel as a number crunching machine to export results to a third party application.
I have a client who uses Excel to churn out management reports about their product sales, profits and so on. The reports that people read in this case are summaries (often from pivot tables), and the chance of them actually seeing a number on those summaries with this bug are vanishingly small. However, they use the underlying basic calculation data to export and feed into their ERP system, and here there is a risk that a number could be passed through at the wrong value via a CSV file. Chances? Small, but not sufficiently small to be ignored.
FUD is in the air
There is unfortunately a lot of sidetracking and “fear, uncertainty and doubt” (FUD) in the comments to that article about floating point accuracy in principle. No-one has ever claimed that Excel or any other calculation program using floating point arithmetic is always totally accurate to an infinite number of decimal places, this is inherently unachievable using binary notation to store fractions and display the results in decimal. At face value it seems annoying that Excel does not treat the calculation of “simple” numbers such as 4.1-4 correctly and get exactly 0.1 (rather than 0.0999999999999996 which it does get).
The reality is that in most cases no-one is looking at enough decimal places to notice or care, or even for the error to compound up into something important. On the flip side, Excel will happily handle arbitrarily small binary fractions such as 1/18,446,744,073,709,551,616 + 1/4,294,967,296 without blinking. A human trying to work on such numbers would inevitably at some point convert them to that strange human notation called decimal and lose some accuracy.
Normally, Excel handles these rounding errors gracefully, and still displays something very near to the correct value, since the error is usually down in the dozens of decimal places. The oddity on this occasion is that for some reason it makes a bad assumption as to what constitutes a reasonable value to display and gets it rather visibly wrong.
I will of course post an update once a fix is available.
