As of today, fixes for this issue in Excel 2007 and Excel Services 2007 are available for download…We are in the process of adding this fix to Microsoft Update so that it will get automatically pushed to users running Excel 2007 or Excel Services 2007.  Additionally, the fix will also be contained in the first service pack of Office 2007 when it is released (the release date for SP1 of Office 2007 has not been finalized).

Microsoft knowledgebase article KB943075 discusses the fix and gives the usual details for what versions and sizes the updated files should have after the fix. The version number of Excel.exe is altered from 12.0.6024.5000 to 12.0.6042.5000. Now read that again – yes, easy to miss the difference from ‘24′ to ‘42′ if you look too quickly. (NB: you may have a different version, mine is at 12.0.6024 after installing the security update as per KB936509, as far as I can tell.)

The download for the fix for Excel 2007 (33Mb exe file) is linked from the Excel team blog as well as from the KB article. The blog post also has links for Excel Services 2007, both 32 bit and 64 bit.

A few people in the comments thread in the Excel team blog post about the bug seem to have some misconceptions about the seriousness of the problem. Some have asked how often it is likely to come up, implying that they think it is vanishingly unlikely. This seems to be particularly those who have misunderstood that the example of 850*77.1 is only one simple example which is easy to remember and to type, but there are several more simple ones as well as thousands of other combinations which lead to the buggy result (due to floating point rounding errors in the calculation hitting a result which is sufficiently close to 65,535 to cause the false display of 100,000). Nine examples are shown in the screenshot below, and in a table you can easily copy and paste to try this for yourself.

Nine examples of simple calculations which Excel can’t work out*

* yes, I know the underlying value in the answer is as accurate as any previous version within the limits of the floating point calculation method and it just displays wrong, but in the real world that’s just as bad.

To use the examples in the table above, select them, copy (CTRL-C), open Excel.
With cell A1 selected go to Paste Special (use the dropdown arrow on the Paste button or do ALT, E, S). Choose Text and click OK.

If you divide 65,535 by integers starting from 1, then multiply the result by the same integer, you will quickly find many instances of the display bug. For example, A7=65535/7; B7=A7*7 (I actually used the ROW() function to generate these so  I could copy and paste blocks quickly). For the integers 1 to 256, you will get 30 examples, the first being 65536/13=5041.15384615385, and 13*5041.15384615385 = 100,000.

How many more examples are there?

In the first 524,280 results, there are 80,242 bugs, which is approximately 15.3%. I do not consider this many to be rare, although I accept that these are all effectively getting one of a very few values close to 65,535 which have the bug – the number of buggy values is small, but the combinations of number pairs which lead to them is quite large. The nine examples given above all have exactly the same product – 65,534.999999999993 (you can see this as the value stored if you open the XML file for that worksheet)

There are several places where as many as seven consecutive integers lead to the bug; the first sequence this long starts at 100,334, the first set of six begins at 31,745. The longest gap I found in the first half million or so cases is 1,370 between the bugs at 262,589 and 263,959.

There are some interesting patterns to the integers which cause these. For example, 13*2^n, 49*2^n, 81*2^n and many other similar chains produce the bug.

Doing a similar exercise on numbers with exactly one decimal place (1.1, 1.2 … 52429.7 but not 1.0, 2.0 etc.) there are 64,325 bug pairs, about 13.64% of results. There is a sequence of 8 numbers from 28,059.0 to 28,059.7 which all produce the problem. A few simple example pairs include 20.4 * 3,212.5, 40.8 * 1,606.25 and 212.5 * 308.4. It starts to become clearer that there are quite a lot of calculations which could occur in normal business models and give rise to the error.

Can I test my files to see if this is affecting my results?

Simon Murphy has published some code which you can use to test your files for occurrences of the bug. He also discusses how important this bug is overall, in terms of actual impact to real users – noting that the number of people who have moved to excel 2007 so far seems to be relatively small. Not zero, but the problem would have had loads more impact if it had been undiscovered for another three to six months. I have a client who are rolling out as I write, migrating several thousand users from Office 2000 to Office 2007. They generate huge management accounting spreadsheets which spit out pretty reports on the one hand, but on the other the data they generate is piped via CSV into their ERP system. So one person would have a chart or summary table with correct figures, while the back-end systems would be out by a significant margin of error. This could take a long time before anyone could have isolated the error and it’s source.

What about cases where this becomes an actual error in the value?

As previously discussed, there are several ways in which the display error can become fixed as an incorrect value (of 100,000 or 100,001):

• using the ROUND function (but not ROUNDDOWN nor ROUNDUP)
• using “precision as displayed”
• exporting to CSV
• Paste Special > Values
• using the TEXT function to convert to a string

In addition, the MOD function seems to just break down altogether – it does not use the 100,000 but returns totally bogus results.
For example, MOD(850 * 77.1, n) gives -7.27596E-12 for integer values of n including 1 and 5 (which should both return 0). even MOD(65534.999999999999,1) gives a result of 0.999999999999 quite happily. Something quite odd going on with this, as MOD should never return a negative value, mathematically speaking.

So what functions work safely?

In addition to the obvious mundane arithmetical calculations, most functions seem to work just fine. The MAX and MIN functions and their cousins LARGE and SMALL work as normal, as do conditional formats including data bars and colour scales. The screenshot on the right shows how odd this may appear.

The FLOOR and INT functions seem to use the correct underlying values and not propagate the error at all. ABS does not change the value, by design (just lose the sign) so it repeats the 100,000 display bug, but still does not lock this in. ABS(-850*77.1) shows 100,000. Adding 2 to that result gives 65,537.

ROUNDDOWN and ROUNDUP both seem to happily return 65,535 as their result. Of course, as Erich Neuwirth pointed out in the Google Groups thread on the subject of the bug, in a way this should not be the case. We know that the result of 850*77.1 is not actually 65,535 but a tiny fraction under that due to floating point inaccuracies.
So that would mean that ROUNDDOWN (850 * 77.1, 0) should truncate the entire part of the number after the decimal point to give a result of 65,534. Now that would be seen as a bug, since we know that in reality 850*77.1 is actually 65,535 exactly. So there must be something in the algorithm for ROUNDDOWN which assumes if a number is close enough to a whole number, round it up to that value, treat it as an integer input and ROUND it down by precisely nothing. The same applies for ROUNDDOWN used for any number of decimal places up to 30 – it spits out 65,535 as if the inaccurate interim value never existed.

I am happy to continue saying “ROUNDDOWN is correct” in this context, since it is closer to our expectations than if every floating point error introduced were to cause whole numbers to be lost. A dollar here, a barrel of oil there, a square mile of land for someone else. This would not be acceptable, but I can accept that the number stored underneath is inaccurate to some bazillionths of a penny. Same goes for the other functions such as INT and FLOOR – they are actually giving incorrect results, but they are giving the result they should in a normal decimal universe.

Of course, if you are a nuclear physicist you don’t want Excel making these assumptions on your behalf for very small numbers, as they would be considered wrong in that context.

Don’t forget, these floating point errors have been around for a very long time. It is only a bug like this that makes people take notice what is going on “under the hood” and try to grasp the idea that their entire accounting career has been a lie, and every report they ever wrote was probably some kind of approximation. People generally fall into three camps on this:

1. Blissfully unaware that their figures are inaccurate, and totally unaffected by the fact
2. Aware that these errors exist in the n’th decimal place as a matter of fact, but happy to accept that this is not fatal
3. Fully aware of the floating point problem, and careful to check that functions handle very-near-integers sensibly to give a result which would be expected in the real world if calculated in decimal.

Which type are you?

Spread the word :

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 numbers 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.

Spread the word: