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.
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
"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
Sufficiently advanced incompetence is indistinguishable from malice.
That profoundly unfunny post (but insightful) will probably get modded as funny.
:-)
Lets wait and see
Ian Ameline
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,
A number of people have verified the bug, and it's quite improbable they ALL have the same model of CPU.
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.
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
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?
...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.
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.
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.