Ms Excel 2007 Piece Of Sh.t

[Richard-BKK]

Thinking why Thai's always recalculate anything, even if it comes out of Excel.....God bless them because Microsoft thinks that 850x77.1 = 100,000.....

To try it for yourself, open up Excel 2007 and multiply 850 by 77.1. If you’re unfamiliar with performing calculations in Excel, you’d enter the following into a cell: =850*77.1 Once you do that, you’ll discover the answer according to Excel 2007 is 100,000. The answer is really 65,535

[Pomthai]

Office 2003 gets the correct answer. I wonder why they have regressed when they should be improving. Oh well.

[Tywais]

That's not good! Just tried it and definitely wrong, even trying different data formats doesn't fix it. Use a slightly different number for the decimal, such as .09999 rather then .1 and it's ok. Wonder what else is broken?

[nikster]

Argh. That's horrible.

[Guest Reimar]

More horrible, take a look at the pic (all same calculation!)

[RKASA]

Does it round other numbers is something set that rounds up to 100k. other number like 65 to 100 and 650 to 1000 something like that?

[JetsetBkk]

Thinking why Thai's always recalculate anything, even if it comes out of Excel.....God bless them because Microsoft thinks that 850x77.1 = 100,000.....

To try it for yourself, open up Excel 2007 and multiply 850 by 77.1. If you’re unfamiliar with performing calculations in Excel, you’d enter the following into a cell: =850*77.1 Once you do that, you’ll discover the answer according to Excel 2007 is 100,000. The answer is really 65,535

Very interesting!

65535 (64k) is FFFF in hexadecimal, or 1111 1111 1111 1111 in binary, so they've probably screwed up the code that decides when to change from two bytes to store the number, to four bytes.

My Firefox calculator extension gives the answer as 65534.99999999999,

whereas the Windows XP calculator program gives it as exactly 65535 - which is correct.

[JetsetBkk]

Lots of results from Google on this bug:

http://72.14.205.104/search?hl=en&q=Ex...G=Google+Search

[Tywais]

Lots of results from Google on this bug:

http://72.14.205.104/search?hl=en&q=Ex...G=Google+Search

Microsoft Acknowledges Floating Point Bug in Excel 2007

By Scott M. Fulton, III, BetaNews

September 26, 2007, 10:51 AM

Source: BetaNews

[Maestro]

Don’t anybody think you can get your money back for your Excel 2007. Read the license agreement, which is only 10,376 words long.

“...LIMITED WARRANTY. If you follow the instructions, the software will perform substantially as described in the Microsoft materials that you receive in or with the software...”

Substantially, Excel calculates correctly. The problem with 850*77.1 is a very rare exception. You can, of course, sue Microsoft and see who wins.

--

Maestro

[Tywais]

Substantially, Excel calculates correctly. The problem with 850*77.1 is a very rare exception.

True it is rare but working in the sciences where we can not afford even a very rare exception in data analysis, I will be informing the staff to continue using 2003 until it is a zero exception in Excel. For me it's not such an issue since I use SigmaPlot for all my analysis, but many researchers here do use Excel.

[Richard-BKK]

Hi Tywais, quote "The problem with 850*77.1 is a very rare exception" you know what is really RARE? It is rare that Microsoft brings something on the market that actual works as it needs to.

I'm thinking to include an additional non-liable act into our sales and service terms, other then "we are not liable for events during a natural disaster" I'm thinking about "we not liable for problems caused directly or indirectly by Microsoft software products or services"

[RKASA]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1 or does it just happen if these are used.?  

edit 425 not 450

forgot to mention 850 items in stock at 77.1 each is not at all rare. Bin it.

[Tywais]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

[RKASA]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

COOL!  

[JetsetBkk]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

COOL!

As M$ says, the actual result stored in memory is correct, so it's the process that converts this number into characters to be displayed that is faulty. So any computation that produces the same number in memory would have the same wrongly displayed result.

It could be - but probably isn't - something as simple as this:

1. the 'displaying' routine wants to display 65535 plus one bit.

2. hexadecimal for 65535 is FFFF

3. add one bit to hexadecimal FFFF and you get 10000 - i.e. zero all digits and stick a '1' in front

4. but the 'displaying' routine wrongly uses decimal 65535 - zero all digits and stick a '1' in front: gives 100,000. QED

[Hmmm]

This is a minor bug that will be fixed quickly with an update.

However Excel 2007 still has serious problems for power users, whereby charting of large amounts of data is so slow as to be unusable. The same tasks complete immediately under Excel 2003.

The one 'hotfix' issued so far had little effect.

This problem with the new charting engine was widely reported during the extensive beta program, but Microsoft obviously chose to ignore the problem and release Excel 2007 without fixing it. Shameful.

[sensei]

Just thinking.

I couldn't help but wonder how much holes there are in Vista?

They haven't even stopped patching the old XP when they released it.

How many life support systems in hospitals are using their OS?

Everything seems to be in beta even after they release the next beta.

Shameful indeed.

[Richard-BKK]

After some digging I found that Microsoft was indeed aware of this calculation bug, the bug was already found in one of the beta releases.

Still Microsoft released the software with bug and all, selling a product knowing that it has bugs in the core function of the product is extremely bad practice.

People who use MS Excel are counting on accurate calculations, if I buy software, and somewhere the mouse blinks wrongly or a menu is not working correct I see that as minor bug I can live with...but bugs in the core function I cannot accept.

We send a nice letter to Microsoft demanding our money back, plus compensation for selling us MS Excel. Lets see what happens.....

[Carmine6]

The first listing in a Google search right now is this MS blog:

http://blogs.msdn.com/excel/archive/2007/0...sue-update.aspx

It says it is display issue, not a calculation issue. Can anyone verify that a subsequent calculation using that cell is correct?

The Problem

This issue was introduced when we were making changes to the Excel calculation logic in the Office 2007 time frame. Specifically, Excel incorrectly displays the result of a calculation in 12 very specific cases (outlined below). The key here is that the issue is actually not in the calculation itself (the result of the calculation stored in Excel’s memory is correct), but only in the result that is shown in the sheet. 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 what, specifically, are the values that cause this display problem? Of the 9.214*10^18 different floating point numbers that Excel 2007 can store, there are 6 floating point numbers (using binary representation) between 65534.99999999995 and 65535, and 6 between 65535.99999999995 and 65536 that cause this problem. You can’t actually enter these numbers into Excel directly (since Excel will round to 15 digits on entry), but any calculation returning one of those results will display this issue if the results of the calculation are displayed in a cell. All other calculation results are not affected.

[RKASA]

Someone here in Thailand I think it was said that Linux is full of bugs, and I read a response to it that said  "yes, but they a cheaper then M$ bugs"  

[elkangorito]

Well, I use Office 2000. No bugs at all.

I'm buggered if I know why people rush out & buy the latest MacroHard software . Personally, I will wait until the MacroHard software has been "out there" for 1 year before I even think about buying it.

[Hmmm]

Well, I use Office 2000. No bugs at all.

I'm buggered if I know why people rush out & buy the latest MacroHard software . Personally, I will wait until the MacroHard software has been "out there" for 1 year before I even think about buying it.

Normally this is very good advice. Windows 98, NT, XP, and Office 2003 all had at least one SP out before I migrated to them.

Migrate when you need to, not when MS tells you to.

Unfotunately Excel 2007 is the first to offer greater than 256 columns, which I really need for my work.

[dsys]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

COOL!

As M$ says, the actual result stored in memory is correct, so it's the process that converts this number into characters to be displayed that is faulty. So any computation that produces the same number in memory would have the same wrongly displayed result.

It could be - but probably isn't - something as simple as this:

1. the 'displaying' routine wants to display 65535 plus one bit.

2. hexadecimal for 65535 is FFFF

3. add one bit to hexadecimal FFFF and you get 10000 - i.e. zero all digits and stick a '1' in front

4. but the 'displaying' routine wrongly uses decimal 65535 - zero all digits and stick a '1' in front: gives 100,000. QED

Why does =850*77+850*0.1 give the correct answer?

[elkangorito]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

COOL!

As M$ says, the actual result stored in memory is correct, so it's the process that converts this number into characters to be displayed that is faulty. So any computation that produces the same number in memory would have the same wrongly displayed result.

It could be - but probably isn't - something as simple as this:

1. the 'displaying' routine wants to display 65535 plus one bit.

2. hexadecimal for 65535 is FFFF

3. add one bit to hexadecimal FFFF and you get 10000 - i.e. zero all digits and stick a '1' in front

4. but the 'displaying' routine wrongly uses decimal 65535 - zero all digits and stick a '1' in front: gives 100,000. QED

Why does =850*77+850*0.1 give the correct answer?

Who knows & who cares? The big question is why it can't correctly multiply 850 by 77.1.

[dsys]

but you can i just showed you how

[elkangorito]

Interresting

I don't have excel so I can't try it, but what about ((425*2)*77.1) or (850*(38.55*2)) is it the same as 850*77.1 point being which part is cause the 850 or the 77.1

Both of those create the same results, 100000.

COOL!

As M$ says, the actual result stored in memory is correct, so it's the process that converts this number into characters to be displayed that is faulty. So any computation that produces the same number in memory would have the same wrongly displayed result.

It could be - but probably isn't - something as simple as this:

1. the 'displaying' routine wants to display 65535 plus one bit.

2. hexadecimal for 65535 is FFFF

3. add one bit to hexadecimal FFFF and you get 10000 - i.e. zero all digits and stick a '1' in front

4. but the 'displaying' routine wrongly uses decimal 65535 - zero all digits and stick a '1' in front: gives 100,000. QED

Why does =850*77+850*0.1 give the correct answer?

Who knows & who cares? The big question is why it can't correctly multiply 850 by 77.1.

but you can i just showed you how

I can see the MacroHard update now;

"Excel users must not, in any way shape or form, multiply 850 by 77.1. If this is required, please do the following;

850*77+850*0.1

Always looking after you,

MacroHard."

Are you nuts?????

[dsys]

no not nuts ........just pointing out the fact that the error cannot be based only in the display code, as stated in the blog mentioned. Probably the reason it hasn't been fixed already.

edit:remove quote

[nikster]

FYI the bug has been fixed now, a patch is available here:

http://support.microsoft.com/?scid=kb%3Ben...mp;x=11&y=9

[Richard-BKK]

Yes fix now.....but still a display error not a calculating error....must be a joke, if people want to calculations I print it needs to be right number on the paper (and I need to be able to trust it)

That Microsoft is talking about a displaying error, is just MS trying to talk down the seriousness of the error...