Slashdot Mirror
Excel 2007 Multiplication Bug
tibbar66 writes with news of a serious multiplication bug in Excel 2007, which has been reported to the company. The example that first came to light is =850*77.1 — which gives a result of 100,000 instead of the correct 65,535. It seems that any formula that should evaluate to 65,535 will act strangely. One poster in the forum noted these behaviors: "Suppose the formula is in A1. =A1+1 returns 100,001, which appears to show the formula is in fact 100,000... =A1*2 returns 131,070, as if A1 had 65,535 (which it should have been). =A1*1 keeps it at 100,000. =A1-1 returns 65,534. =A1/1 is still 100,000. =A1/2 returns 32767.5."
I bought a Dell this year, it came with Office 2003.
How we know is more important than what we know.
well, it could very well lead to massive fuckups if anyone happens to make a decision based on the flawed result.
If you mod me down, I will become more powerful than you can imagine....
If they are using Excel to analyze their data, I don't want to drive over a bridge they are designing...
None of the math or physics folks I work with would think about using Excel for their data.
Never attribute to malice what can be adequately explained by incompetence.
Control is an illusion, order our comforting lie. From chaos, through chaos, into chaos we fly
I use Matlab and Octave constantly for things everyone around me uses Excel for (I do structural engineering). I am no amazing hacker or anything, but I simply find it scads easier to use that sort of paradigm over the spreadsheet analogy for almost any application. That aside, Excel in particular seems constantly to try to outthink me and consistently to have these sorts of strange calculation errors.
Here's a tip. If an application can cause a kernel fault, it's not the application that is broken.
How we know is more important than what we know.
Just for the heck of it. There's always an offbeat chance that the multiply bug is in the CPU, not Excel....
This is my sig.
Yeah...cause the chances of having a number evaluate to 65,535 via multiplication is extremely common.
What are the odds of that bug only affecting that number? It's a symptom that the underlying routine is totally fscked, in ways that could cause nasty surprises.
If it gave the wrong answer all the time you'd know it was crap and would just ignore the whole thing. It's when it only gives wrong answers some of the time that can lead you into a false sense of confidence.
You've also got to wonder, if it worked fine in previous versions of Excel, what the frack they were messing with to hose it up. It's not like somebody changed the rules of arithmetic recently, did they?
-- Alastair
Let's see, on one hand, we have a 16-bit integer. On the other hand, we have computers that can do almost a billion multiplies per second. Nope, shouldn't be a problem... oh wait. The Pentium bug was much more difficult to hit, yet with millions of them out there, people managed to hit it while doing important computations (money, safety, etc). Another post mentions structural engineers using Excel, and I doubt they are doing just simple sums and averages; Would you really want go through an earthquake in a building with safety margins calculated in Excel?
"cause the chances of having a number evaluate to 65,535 via multiplication is extremely common."
"No it doesn't really affect anything. "
Oh, it's only the largest unsigned 16 bit number and comes up in a crapload of places. Enough times that you should have _memorized_ it by now.
Jeez. Please turn in your geek card NOW.
--
BMO
If an application can cause a kernel fault, it's not only the application that is broken.
There, fixed that for you.
-- Alastair
Sufficiently advanced incompetence is indistinguishable from malice.
I find this bug kinda ironic since one of the big pros attributed to Excel over OO Calc is that it is so useful for data manipulation. Yet, the number which results in the bug isn't ever a particularly big number - well within a practical use case.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
That profoundly unfunny post (but insightful) will probably get modded as funny.
:-)
Lets wait and see
Ian Ameline
Huh.. Excel works fine where I work. They have all sorts of network drawings in Excel...
What? Hey, stop laughing. I'm serious! You should see these things.. Massive diagrams all built using the draw toolbar in Excel...
Personally, I've found Visio to work out nicely for network drawings, but apparently the other engineers like Excel...
Speaking of which.. Anyone know of a decent OSS replacement for Visio? And no, dia doesn't count. It's nowhere near what Visio does. Nor does it save a Visio compatible file.
XenoPhage
Technological Musings
Not the point. The fix would probably be available within minutes if the source code were open. Plus, a more rigorous review would have been triggered to make sure there aren't more errors of the same type...
With Microsoft, we will be waiting for days before they even notice it...
As such, their product stands unusable, possibly for weeks. And there is nothing we can do about it, not even sue for lost profits or damages.
I am pretty sure those that bought Office at an academic/company discount would also not be able to return it.
Obama likes poor people so much, he wants to make more of them.
Crazy stuff. I could have sworn that MS had some resources allocated to doing huge beta tests.
For that matter, they probably assign people to create scripts to randomly create calculations and test the results. However, after reading a bit of the Usenet thread, automated scripts might not have caught the problem, it seems that it is at the rendering layer - using VB to get the cell value apparently gets the correct value.
Weird. And highly embarrassing.
I can't wait for the advertisements from OpenOffice (and it's new allies in IBM and Google) to play this up! Apple will have a field day too -- "Hi, I'm a Mac. Sure I'm good at video and music and all that fun stuff, but I can also do math. I know that 65,535 doesn't equal 100,000." -- OK, maybe that wouldn't be TV worthy, but I'll make a good web ad for Slashdot et. al.
MSOffice doesn't run on the operating system, it runs the operating system.
Lacking <sarcasm> tags,
I'd say the chances of it only effecting this number are quite high.
I'm not the only one that recognised this as the 16bit number (see some of the other posts in this thread).
I'd wager a fair amount of money to say that numbers under 65535 are represented as 16 bit ints but anything over that number is changed on the backend to possibly a 32bit number. This allows faster calculations of smaller numbers (which happen quite a lot) while still allowing higher numbers to be used. The developers created this system, but forgot to test the edge cases (though it can be argued that they don't test any cases before release). If it were to happen to any other number, it would either be at the 8 bit number (though I doubt it) or at the 32/64 bit number they use for the larger values.
Agreed. But just because a buggy kernel lets an app cause a kernel fault doesn't mean that the app itself is not buggy also. The kernel bug needs to be fixed first, but that's no guarantee that the app will then behave properly.
-- Alastair
Right, he was joking dumb ass.
You wanted to see 65,535 and other popular numbers in spreadsheet results? You need Excel Penultimate Edition for that sir!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Apparently, someone's never read the The Restaurant at the End of The Universe.
CAD derivatives are quicker, less precise, like a blaster vs a light saber, only few use light sabers, many use blasters.
Under the influence of Post-Cyberpunk Gonzo Journalism
Come on /. let's see how far this can be reduced before we use a piece of silicon (If that is required).
Now, unless I'm mistaken, this reduces to:
4*5*7*11*17*29*31*37*41*43*47*53
which you'll notice is the multiplication of all prime numbers between 53 and 27 (inclusive). I can't spot any further properties, hence probably need somebody to check this.
.
Why does it have to be astroturfing? Why can't he just be wrong?
You'd better watch out, if your knee keeps jerking that high you might catch yourself on the chin.
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
Thats actually a pretty good theory. Especially in light of the fact that this appears to be a display bug. (ie the data thats actually in the cell is correct, its just printing wrong) Of course, we will never actually know. :)
http://digg.com/microsoft/Critical_Excel_2007_bug_cripples_users
Rubbish.
spreadsheets have their place.
Just about every engineer I know (and yes, IAAE)uses Excel for calculations with no issues at all. Yes they use more specialised (and expensive) tools for things like Finite Element analysis (ie bridges, etc.) and so on, but a lot of everyday stuff gets done on spreadsheets.
Everything from hydraulic calculations to reinforcing quantities can be done in a spreadsheet.
However it would be a mistake to rely solely on results produced by any software without using some judgement on the results. Problems come when people get too trusting of software, whether its a spreadsheet or a $20,000 Analysis package.
Mind you, none of the engineers I know are using Excel 2007 yet, and aren't likely to while this sort of problem is out there.
If my call is important, why am I talking to a recording?
Why is this modded Insightful?
...and if you click allow and get the wrong result, then it's all your fault.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Besides, 65535 is at the top end of the unsigned 16-bit int range, which seems an odd type to be using for spreadsheet calculations (where negative values are as likely as positive).
This depends on the type of data that is being worked on. A financial ledger may have numbers that are positive, negative or some scalar of i . Census or poll data, mileage charts, employee time-sheets or transactions/time (to name a few),however, will seldom have negative numbers.
A large number of x86/x64 systems now have support for SSE and MMX instructions which, if done right, could provide a significant speed increase when working with a large set of small numbers. However, many instructions in these extensions behave in an data destructive manner when an overflow condition is encountered. For example, when working with saturation arithmetic instructions you may compare the result with $FFFF and, on a match, branch to code that handles a saturation condition on the assumption that the real result is greater than $FFFF. Such an approach works fine until you encounter a situation where $FFFF is the correct result but the program flow jumps to the saturation handler anyway, possibly with garbage data stuffed in registers that would normally be used to pass values to the handler.
Of course it's just speculation that they attempted to optimize the offending function in assembly; and it's further speculation that they chose to optimize it with SIMD instructions. However the fact that this bug appears right at the edge of the unsigned 16-bit integer range really does suggest that somebody was trying to do something clever in assembly and failed to account for all possible conditions.
If anyone out there is bored and has read this far, try timing a few operations on a large set of small integers in Excel 2007 and then toggle off SSE/SSE2 in BIOS and time the same set again. I'm curious as to whether or not MS did do this sort of optimization but I'm not curious enough to borrow a copy of Excel from The Pirate Bay just for this test.
My God! It's full of eval()'s.
Fixing time is proportional to the coolness points you get for fixing the bug.
Ermmm... It's spelled "OS X" and pronounced "oh ess ten". OS 1 - 9 did exist; they simply weren't designated with Roman numerals.
http://en.wikipedia.org/wiki/OS_X#Versions
Do not compare floating point numbers for equality. Doing so is almost always a bug.
Do not use floating point for financial calculations. Doing so is always a bug.
You know, some people actually read and use the displayed results from Excel for important purposes, rather than merely feeding them into further calculations, graphs, etc. Where the cell is an ultimate output, this isn't just a harmless display error that doesn't have any functional impact.
You don't use floating point numbers for financial calculations.
They need to use "decimal".
The decimal type is floating point, just not binary. But yes, that's the type to use, because the problem isn't the floating point, but the base conversions.
See, I use Firefox all day, every day, and I have yet to have an issue with it. So you aren't reporting "showstopper" bugs, that NEED to be fixed in the current version. You're reporting "nice to have" bugs that will be fixed in a future version. And as soon as FF3.0 is out, you'll have to shell out an arm and a leg to get it, so you're locked into their upgrade path... wait, what? It's free you say? Well shit, they're taking your suggestions seriously, incorporating it into a world-class product, and giving it to you for free!?! Those bastards!
My blog. Good stuff (when I remember to update it). Read it.
Typical Slashdot. In the end the vast majority of people who use Firefox aren't even coders. You seriously want them to grab the fix from CVS and backport it to their own copy? My God man, these people don't even know what make does, and what are you suggesting?
There's nothing for open source apologists to gloat about when it comes to software fixes. As far as any normal user is concerned, bug fixes take just as long to come down the pipe as proprietary software. Nobody gives a hoot if it's fixed in CVS, if it's not fixed on their machine it's not fixed at all.