Comments on: Excel 2007 calculation bug displays apparently wrong numbers

By: Adam Vero

Adam Vero — Thu, 18 Aug 2011 16:13:28 +0000

Katie
What values are actually in the cells you are adding up? If you change the number of decimal places shown in those cells, does it still show .8200000, .9400000 and .3600000? Or is the displayed value slightly different?
If you had, for example, .818, .937 and .355 you would get a SUM of exactly 2.110, but these numbers would look like yours if shown to two decimals only.
If they were a bit higher such as .819, .938 and .357 you would get 2.114 which would show 2.11 if only two decimals are visible.
Hope this helps
Adam

By: Katie

Katie — Thu, 18 Aug 2011 16:08:17 +0000

My problem is in simple addition. If I add a column of numbers using the SUM function, not always, but sometimes it gives the incorrect answer, even allowing for rounding. Example: if you add these figures .82, .94, .36, you should get something ending with .12. Not on my spreadsheet. It shows the answer ends with .11. A calculator, or a real throwback to pencil and paper, will prove the .11 is absolutely wrong. A penny may not seem like much, but for what I’m doing, it has to be completely correct. How do I make it work right – like any third grader could add?

By: Adam Vero

Adam Vero — Fri, 05 Sep 2008 06:37:45 +0000

Norm
Can you be a bit more specific about what actual numbers you expected to appear?
It sounds like you simply need to change the number format for those cells to show more decimal places – on the Home Ribbon in the Number group, click on the button with a blue arrow pointing left and “.0″ above “.00″. Or just click the comma to get two decimals with commas between the thousands.
If the result in I21 was (say) 12.12 dollars and this was displayed with no decimal places it would show 12. Multiplying by 2 gives 24.24 which would still show 24 if you have no decimals.
Try I25=1000*I21 and see what shakes.
Turn off “Set precision as diaplayed” since that means any cell where you are not showing the full stored value will actually get rounded down to the value it shows, so when you multiply back up again you get weird results. For example:
A1=1234
A2=A1/100 gives 12.34, but if you display this with no decimals it shows 12, even though 12.34 is stored.
A3=A2*100 gives back 1234.
However, if you have “Set precision as displayed” then A2 would actually contain 12, and A3 would show 1200.
There are very few times that this option gives the results you really want, and many more where it confuses matters.

By: Norm

Norm — Thu, 04 Sep 2008 20:00:31 +0000

I had a cell, I21, that was =(D10*12)-I20 the number was a dollar value. Excel rounded it to the nearest whole dollar for no apparent reason. I tested the idea that the stored information was correct by creating a new cell I25 and making I25 =2*I21 the result was still rounded. I applied the options>advanced> turn on “Set precision as displayed” and it seemed to fix it. I25 is showing the correct value as well. Can someone explain the caveats for the rest of the workbook?

By: Adam Vero

Adam Vero — Fri, 27 Jun 2008 18:34:43 +0000

Unfortunately, Brenda, Excel has a hard-coded limit of 15 significant digits that it will store and use for calculations. The method used for encoding and storing numbers is based on the popular IEEE 754-1985 floating point standard. You can read more about the significant digits and other limitations of Excel, most of which became significantly larger for Excel 2007 (number of rows and columns being particularly well-known, others relating to charts and pivot tables just as valuable but less talked about). You could import those values as text if they are only for reference. If you need to treat them as numbers for calculations then just about the easiest option you have would be to bring in the data and split it into two fields - for example a "billions" column and "the rest". This would make calculations much harder to sort out, but might be possible depending on what you need to do. If the results needed more than 15 significant figures you would still lose some accuracy, but at least this would be a small part of the result rather than of several inputs which could compound to a greater variance in the end.

By: brenda ruppert

brenda ruppert — Fri, 27 Jun 2008 18:09:30 +0000

My problem is not decimals or multiplication. I import data that has a column of 16-digit numbers, and instead of the number ending in 128 for example, it changes the last 3 digits to 120. How can I fix this?

By: Excel 2007 bug shows wrong answers to simple multiplications « Getting IT Right

Tue, 02 Oct 2007 14:04:40 +0000

A follow-up to this post with more examples of buggy calculations and information about the propagation of incorrect values can be found here:
http://veroblog.wordpress.com/2007/10/02/excel-2007-bug-shows-wrong-answers-to-simple-multiplications/

By: Adam Vero

Adam Vero — Fri, 28 Sep 2007 06:41:48 +0000

You are right, Joel does have a pretty good explanation of what is going on under the hood if you wish to understand more about binary representations of floating point math. The only thing he misses is explaining when this so-called display bug becomes an actual wrong value, which is far more dangerous to users. He also has me looking skywards for falling meteorites - or should that be Meteor ITs?

By: budhie

budhie — Fri, 28 Sep 2007 06:36:57 +0000

view http://www.joelonsoftware.com/items/2007/09/26b.html for excel bug explain

By: Adam Vero

Adam Vero — Fri, 28 Sep 2007 06:21:02 +0000

BOBV
If you do B1=A1*1 you should see 100,000 as there is no change to the value since 1 has a perfect representation in floating point arithmetic and does not cause any rounding of the result to get out of the cycle of the bug. B1 actually contains almost 65,535 but displays 100,000.
If you use A1+1 you get 100,001 because of the second bug near 65,536. However, A1*2 or A1+2 or A1/2 all give rise to a correct result.

Well done for spotting Paste > Values. This must be using the same process that works for pasting out to non-formatted applications such as Notepad, or exporting to CSV.

As you say, the risk here is that on large spreadsheets this would be impossible to spot by manual checking, although it must be accepted that the actual chances of generating one of these results in reality is extremely small – but not quite small enough for us to take comfort from it.