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

Microsoft just announced plans for their fix

[Anonymous Coward]

They will be disabling multiplication in all future versions of Excel.

Re:Microsoft just announced plans for their fix

[cloricus]

It is nice to see that since this is a free and open standard that the bug has been identified quickly and fixed.

Oh wait, it isn't and the bug is still at large. Sorry, jumped the gun there due to the speed at which the Open Source community usually fixes issues like this. Maybe ISO should take note.

Re:Microsoft just announced plans for their fix

[p0tat03]

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.

Re:Microsoft just announced plans for their fix

[Waffle Iron]

Microsoft already has a patch in the works to help users overcome this issue. Whenever the user types a '*' in a formula, an animated sprite of Charles Babbage's head will pop up. It will show this bubble caption:

"It looks like you're trying to multiply two numbers. I can help show you how to use the Method of Finite Differences to find a good approximation of your answer using only addition and subtraction. Would you like me to bring up a wizard so that we can get started on finding an appropriate power series?"

Re:Microsoft just announced plans for their fix

[edittard]

What you need is specialised hardware [wikipedia.org].

Re:Microsoft just announced plans for their fix

[FelixGordon]

It looks more like the result of an overflow error at some stage of the calculation, since 65535 is the maximum value an unsigned 16 bit integer can hold.

Re:Pido libro de reclamaciones por daños.

[jandrese]

Wow, that was a lot of work to demonstrate that a number ending in a 5 isn't prime.

Re:Microsoft just announced plans for their fix

[Bionic Vapour Boy]

This doesn't work either: =850/(1/77.1) So they have to disable the divide-operation altogether.

Re:Microsoft just announced plans for their fix

[jkrise]

They will be disabling multiplication in all future versions of Excel.

No, no, no... remember this is effectively Office Vista.. so the fix will be, like:

You are trying to multiply 2 numbers and the answer is 65535. This is a very dangerous multiplication frequently used in viruses... Cancel / Allow?

Re:Microsoft just announced plans for their fix

[Opportunist]

...and if you click allow and get the wrong result, then it's all your fault.

Re:Microsoft just announced plans for their fix

[CarpetShark]

You are trying to multiply 2 numbers and the answer is 65535. This is a very dangerous multiplication frequently used in viruses... Cancel / Allow?

Oh, is that how it works? I thought it wouldn't show you answers above 255, unless you have a HDCP-compliant monitor.

Re:Microsoft just announced plans for their fix

[nschubach]

Maybe the mod points are being run through Excel before being applied to posts.

Re:Microsoft just announced plans for their fix

[Chainsaw]

Windows 4: "Oh, man. The previous one was garbage, but this one is making me physically ill."
Windows 5: "What the hell have you done? Delete it! Delete it!"
...
Windows 95: "Fuck it, we have to release this steaming pile of crap now.

Just a theory...

The reason it was named "Windows 95"

[Solandri]

For those who don't remember, the reason for the "95" name was likely because Windows "Chicago" kept getting delayed. Eventually Gates announced it was going to be released under the name "Windows 95". Speculation was that the name was chosen to pressure the development team to get it released in 1995 instead of letting it slip to 1996. They released it in late summer 1995, arguably too soon.

In OOXML?

[gvc]

Perhaps this is how multiplication is done in OOXML. They do leap years in dates wrong, too.

Looks like a typo

[jorghis]

Surprised noone has pointed this out yet, but this is likely a hardcoded constant being used when excel converts from a 16 bit number to a 32 bit. It should have been "0x10000" but instead was 100000. Speculation sure, but it looks pretty likely, I mean how else would 100000 randomly appear when you did that computation?

Someone was slacking in the testing department.

Re:Looks like a typo

[Firehed]

Wouldn't that apply to 65,536, rather than 65,535? 65,535 is 0xFFFF, not 0x10000.

I have another theory entirely.

[Mr Z]

...except for the minor detail that 65535 is 0xFFFF... :-)

That said, my 32-bit print routine for a 16-bit CPU actually works by printing two 16 bit numbers, with a slight hack to the 16-bit routine to allow it to print numbers in the range 65536 - 99999 for the lower 5 digits. It does this by dividing the 32-bit number by, you guessed it, 100000. It then prints the quotient and the remainder. It has to do some extra legwork, though, to get the leading zeros right across the two words, and I think it's there that the code went south if they're using a technique similar to mine.

I'm guessing what happened here is that there's an off-by-1 error in a comparison somewhere (i.e. ">= 65535" instead of "> 65535"), and the 32-bit quotient/remainder print routine kicks in. Since the number is already smaller than 100000, it probably hits a fall-thru case where the quotient is assumed to be 1, and there's no remainder, hence it printing 100000.

For reference, here's that assembly code I mentioned: prnum32.asm [spatula-city.org] and prnum16.asm [spatula-city.org]

--Joe

I've got a theory...

[XNormal]

It must be bunnies!

Re:I have another theory entirely.

[gogodidi]

Unless somebody here works for Microsoft who has access to inside information... I'm sure there are hundreds of you, all those anonymous cowards are probably Microsoft employees in disguise!

Re:I have another theory entirely.

[Anonymous Coward]

no, I've asked guys around the office; nobody reads slashdot here.

Re:I have another theory entirely.

[Mr Z]

As Harlan Grove pointed out in the thread, [google.com] some functions may be taking the value from the .Text property rather than the .Value property. Most things see the correct value despite it being misdisplayed.

Why would they do something goofy like that? I have no idea, and I don't have an easy way to check off-hand, at least not in Excel 2007.

And yet it works FINE when you GRAPH it...

[uptownguy]

....interesting twist...

I just fired up Excel and created a simple graph:

One column of numbers was a series from 845-855. The next column was the first column * 77.1. As expected, the series jumped from:

65149.5, 65226.6, 65303.7, 65457.9, 100000, 65612.1, 65689.2, 65766.3...

But then when I created a graph to display this, I had a simple straight line -- trying to plot the single data point represented by "100000" also displayed the accurate number. Any other calculations done with this number yielded the right result, too. Taking the value of the cell that displays100000 and multiplying it by 2 results in 131070.

So all things considered, this really amounts to an Easter Egg. Most spreadsheets will calculate, graph, and function exactly as they should even using the results from a cell that displays inaccurately in that one case...

Re:And yet it works FINE when you GRAPH it...

[fruity_pebbles]

That's true, but if you add 1 to that result you get 65537. And dividing either "1000000" or "100001" by 2 gives the correct results. I can replicate the problem as a display problem, but I can't produce any actual calculation errors.

Re:In OOXML?

[mennucc1]

Perhaps this is how multiplication is done in OOXML. They do leap years in dates wrong, too.

oh my, it is clearly spelled on page 890 of the draft:
to retain backward compatibility with MSDOS 16bit mode, the operands of any multiplication that may exceeds a 16 bit boundary must be converted to farsi and multiplied using an abacus emulator, as per sec (II)par alpha comma 2; the result may or may not appear in Windows Genuine Octal Format (a.k.a. fake octal - that is octal without the leading zero and minus 1) for added convenience of EndUser(tm).

Re:In OOXML?

[Baricom]

I say we petition Microsoft to include a multiplyLikeExcel2007 element in the next version of OOXML.

Re:In OOXML?

[Anonymous Coward]

The OOXML specs are already 65498 pages long. If Microsoft can give "multiplyLikeExcel2007" a 37 page treatment in the OOXML specs, the total page count for OOXML will reach an amazing 100000 pages (therefore 166 times better than ODF). Sounds like a winning plan to me!

Re:In OOXML?

[Anonymous Coward]

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.

Re:

[XenoPhage]

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 compatibl

Re:Wow...

[cyphercell]

CAD derivatives are quicker, less precise, like a blaster vs a light saber, only few use light sabers, many use blasters.

Re:Wow...

[Kreigaffe]

a spot-on analogy involving jedis? you sir win two internets.

Re: Your sig

[Dolda2000]

sed 's/readSlashDot\(\)/meetWomen\(\)/g' braindump.txt

Oh please! Everyone knows that sed uses old-style regexes, where `\(' and `\)' are subpattern delimiters, not literal parentheses. Furthermore, you'd never need to escape parentheses in the replacement part of the command (unless, of course, you use parentheses as command part delimiters).

No wonder you can't meet any women!

Re:In OOXML?

[v1]

I have a spreadsheet I use for my finances, and I have been having to resort to converting some numbers to strings and back again to get around rounding errors, but excel pulled a new one on me. After months of entering my checkbook data, a cell toggled to indicate a balance error. It was something like $1234.56 != $1234.56. I bumped the precision as high as it would go and both cells still showed exactly the same value but would not evaluate as equal. So I set a third cell thusly A3=A2-A1. And the third cell now showed as something like -1.0032E-18. (that's like 0.0000000000000000010032) Lovely. This is not the first time I have encountered cumulative rounding errors in Excel. So now I have to test not for (in)equality, but to test for the difference to be less than 1/100th of a cent. That's BS for a spreadsheet app.

I was surprised to find that the error actually had came up much earlier, but when the difference between cells is less than a certain amount, excel's equality resolves as true. So removing the last few entries, the book balanced again, even though the difference was now -2.18E-19. Clearly they are aware of this problem and are trying to hide it. If it was not actively fudging numbers there would probably be a lot more people having numerical problems. (numbers cited here are illustrations, I do not recall the exact values or precision)

Re:In OOXML?

[Frankie70]

Welcome to the world of Floating point arithmetic.

Look at these articles.

http://support.microsoft.com/kb/q78113/ [microsoft.com]
http://c-faq.com/fp/printfprec.html [c-faq.com]
http://c-faq.com/fp/fpequal.html [c-faq.com]

Microsoft Excel was designed around the IEEE 754 specification with respect to storing and calculating floating-point numbers.

Re:In OOXML?

[norton_I]

Do not compare floating point numbers for equality. Doing so is almost always a bug.

Pentiums

[MyLongNickName]

What happens if you use this on an older Intel chip? Do the issues cancel out?

Re:Pentiums

[644bd346996]

Perhaps. I tried to test it out, but the hard drive with the swapfile caught fire before Excel finished loading.

Re:Pentiums

[Fuji Kitakyusho]

Not quite. The cell in that case just reads 99,999.999998263, when it should be 65,534.99994721.

Is anyone using Excel 2007?

[QuantumG]

I bought a Dell this year, it came with Office 2003.

Yes.

[oatworm]

Yep - my office switched to Vista and Office 2007. Then again, we're a networking firm, so it's in our best interests to use stuff while it's still "beta" so we know the bugs and quirks before our customers start playing with it.

As an aside, when I went to pick up a lease renewal form for my apartment complex, I noticed that the lady at the front counter was also running Office 2007, so I'd say it's out there - just not exceptionally widespread at the moment, compared to other versions of Office.

The renewal form, hmmm?

[NotQuiteReal]

And you didn't balk at the 34% increase in rent?

Re:Is anyone using Excel 2007?

[ultrasound]

I'm using Excel '97 and Word '97 on my XP Pro 2.6GHz dual core and they work fine. Excel loads in an instant, most numbers seem to multiply ok (haven't tested them all but I'm sure the service packs have fixed most major errors by now). In 10 years I haven't seen a single new feature that makes a compelling reason to upgrade.

I started with Excel 2.0*, in those days every release seemed to add significant new features (and floppies) and there was always a rush to install the new version and some excitement as you discovered the new features. By Excel '97 the program was so feature rich that most users never used more than a fraction of its functionality, same goes for Word '97. Where do you go from there?

(OOXML etc, I know).

*I think it was 2.0, it was 20 years ago.

Re:Is anyone using Excel 2007?

[Sam_Brightman]

"most numbers seem to multiply ok"

perhaps making a statement like this about a spreadsheet is not really a shining endorsement. let me know when you've tested the rest of them.

Re:Is anyone using Excel 2007?

[QuantumG]

Of course you did. You don't think they're going to pay you to do bug testing for them do you?

They DO pay you to find bugs ..

[Dr_Barnowl]

... your payment is a free office suite.

Bug finding is a valuable contribution to the value of any product. My current testing policy is to find the biggest pain in the ass in my user community - whoever has the largest bug count from the previous release. And give them the first beta. Every bug squashed improves the product for everyone. The cumulative value can't be ignored.

If you find bugs in any software, it's in your interest to report them, because you obviously want them fixed. If it's a commercial product, you may even be able to get more instant satisfaction. OTOH, for open-source products, I've had an instance where I was able to saunter into an IRC channel, mention a particular bug, and have the lead developer upload a new version to my server within 10 minutes, because he recognised the value of having a technically able user put his product through heavy stress.

Don't just swear and cuss about bugs in OpenOffice. Report them, send them copies of the files that break it. You might get your bug fixed. For free, in the next version. When did you last get that sort of deal from Microsoft?

Who are you going to call?

[renegadesx]

1 2 3 4 5 5 6 7 8 9 10 11 12... ...65,533 65,534 100,000

Give em a break, even the Count from Sesame Street cant count that high.

Re:Who are you going to call?

[dvonhand]

Who are you going to call?

Ghostbusters?

Re:Who are you going to call?

[AJWM]

1 2 3 4 5 5 6 7 8 9

But I think the Count can manage to count to six without stuttering.

Re:Who are you going to call?

[rubycodez]

if you were a real fan you'd know that's when the Counts repeats a number and then comments how wonderful the items being counted are. e.g. five...five *wonderful* vampire bats! mwuhahahahaha!

Re:Who are you going to call?

[halcyon1234]

No, dude, you have it wrong. The Count always stops to repeat every now and then, to remind you of the objects being counted.

1... 2... 3... 4... 5... 5 Mod points for Halcyon! {thunderbolt, lightning, kid-friendly-maniacal laughter}

Re:Who are you going to call?

[OverflowingBitBucket]

1 2 3 4 5 5 6 7 8 9

But I think the Count can manage to count to six without stuttering.

Geez, way to go. Give 'em a chance to fix their current problems before you start finding new ones. ;)

Google Spreadsheet bug

[DJ_Perl]

Open a Google Docs spreadsheet. Type =COMBIN(55,27)

It only gets worse.

[The Earl of Sandwich]

Try =6*9.

Re:It only gets worse.

[$RANDOMLUSER]

Try =6*9.

6 * 9 = 42
What's your point?

Re:It only gets worse.

[MostAwesomeDude]

So this means that Microsoft is the fundamental flaw in the universe? ...Okay, I'm convinced.

Re:

[RobNich]

Perhaps it's because 6 * 9 = 54.

Vista Sales

[xs650]

It's used in the algorithm that MS uses to report Vista sales.

Microsoft Excel is the Worst Part of Office 2007

[ChaoticCoyote]

I use the Office 2007 versions of Word, Excel, and OneNote on a regular basis for my Windows business work; the *only* one I've had *any* trouble with is Excel. I can blue screen my machines with Excel on a regular basis; unfortunately, one of my paying customers requires Excel 2007 because they invested heavily in it (long before I was contracted), so I haven't got much choice, since .xlsx documents won't open in any FOSS spreadsheet apps.

For my personal work, I use Gnumeric on Linux.

Re:

[AJWM]

If an application can cause a kernel fault, it's not only the application that is broken.

There, fixed that for you.

Special powers

[overshoot]

Here's a tip. If an application can cause a kernel fault, it's not the application that is broken.

How many other apps do you know that replace half of the system libraries?

MSOffice doesn't run on the operating system, it runs the operating system.

Re:Special powers

[OverflowingBitBucket]

How many other apps do you know that replace half of the system libraries?

Try an install of the Visual Studio .NET family. Can't remember if it messes with system files but it messes around with Office files, even if Office isn't around. You then need to use Office patches to update them. It's insane.

Check a C multiply on that machine...

[tjstork]

Just for the heck of it. There's always an offbeat chance that the multiply bug is in the CPU, not Excel....

Re:Check a C multiply on that machine...

[The MAZZTer]

A number of people have verified the bug, and it's quite improbable they ALL have the same model of CPU.

I can see the OOXML tag now...

[mad.frog]

<MultiplyLikeExcel2007>
        =850*77.1
</MultiplyLikeExcel2007>

Re:I can see the OOXML tag now...

[ameline]

That profoundly unfunny post (but insightful) will probably get modded as funny.

Lets wait and see :-)

Re:I can see the OOXML tag now...

[Anonymous Coward]

That profoundly uninsightful post (but funny) will probably get modded as insightful.

Lets wait and see :-)

Re:I can see the OOXML tag now...

[l0b0]

That ... *Head explodes*

Re:I can see the OOXML tag now...

[fractoid]

And your rather funny (but not insightful) post will get modded as... bah, nevermind. :P

Unnecessary abstraction

[mikvo]

Multiplication is an unnecessary abstraction anyway. This should really be represented by summing the value of 77.1 entered independently into 850 cells: =sum(a1:a850).

Re:Unnecessary abstraction

[Rick Genter]

I'd prefer to put 850 in 77.1 cells and do =sum(a1:a77.1)

some limited testing

[indaba]

original 850 77.1 100000
425 154.2 100000
212.5 308.4 100000
8500 7.71 100000
but this evaluates correctly..

25 2621.4 65535

so it's not every multiplication that evaluates to 65535

I'm using Excel 2007 12.0.6024.5000

Re:some limited testing

[indaba]

=(8500 * 1) * 7.71
that evaluates to 65535

but :
=850*(771/10) evaluates to 100000

Retro

[starfishsystems]

I always said that Microsoft would never successfully migrate from 16 to 32 bits...

Kinda Ironic

[pembo13]

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.

Imperiled by binary decimals?

[Protoslo]

It sounds like they are doing small-number math in one representation (perhaps they use short fixed-width decimal representations) and then switching to another method (arbitrary length decimal numbers?) at the binary-inspired boundary 2^16...but somehow they got it mixed up with a different decimal boundary in the edge case.

Clearly the error is weirdly subtle, if 5.1*12850 gives the bugged behavior, but 8.5*7710 works just fine. In fact, I verified that all permutations of a bugged combination =A*B of the form =A/2*B*2 are bugged. Further...all of the buggy decimal values have no perfect floating point binary representation. 77.1 has an infinite binary expansion using IEE 754, while 8.5 has an exact representation. It seems likely that they are only using their BCD format (or whatever) when binary floating (or fixed) point just won't cut it, but then their internal->decimal conversion code chokes on 2^16 for some reason, while the binary (whether it is floating or fixed point) conversion works just fine (possibly because it doesn't have a boundary at 2^16--maybe it has its own threshold bugs ;p).

What happened to the beta tests?!

[WoTG]

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.

This is why OOo Calc can never replace Excel

[swillden]

This is yet another example of where Calc fails utterly to be compatible with Excel. How can I use Calc if I can't be sure that it will produce the same answers that my boss gets with Excel?

All those open source developers just don't get it. Geeks that they are, they prize accuracy over consistency and uniformity. The clueless dweebs need to get out of their parents' basements and get a clue about how the REAL WORLD works. Nobody gets promoted for contradicting their boss, duh.

Nope, until Calc can faithfully reproduce every Excel calculation, it simply won't be ready for use in the real world.

Pay Day!

[johkir]

Now how can I work this into my salary.......

Not the only devastating bug

[Casandro]

In the german version there is a bug for almoust a decade now.

If you type in 3.5 you will get "3. Mai". Now if you try to correct yourself by entering 3,5, the correct way to enter decimals in german, you will get "3. Januar". There just is no way for the unexperienced user to get back to normal.
The bug essentially is that the system allows dates without a year.

Step 2 Found!

[OverflowingBitBucket]

Well, I'm off to deposit $655.35 less my current balance into my bank account.

MS Multiplan on Commodore 64

[innocent_white_lamb]

Just for fun I cranked up Microsoft Multiplan 1.06 from 1983 for the Commmodore 64 (using the Vice emulator [viceteam.org], and the magic calculation (850*77.1) gives the correct answer of 65535.
 
I have always been under the impression that Excel was originally based on MS Multiplan (isn't it?) so the code was correct at that time and has become broken at some subsequent point.

basic math errors in MS libs? Nothing new..

[12357bd]

Back in the 386 days, the tan() function returned the wrong sgn if no coprocessor was present. Contacted and confirmed the error they simply ignored such a basic issue, and replied with 'use sin() and cos() functions instead'. Great.

It seems old habits never die!

Re:Oh no!

[timmarhy]

well, it could very well lead to massive fuckups if anyone happens to make a decision based on the flawed result.

Re:Oh no!

[renegadesx]

This just in: Florida plans to do use Microsoft Excel to calculate the 08 election results.

News at 11

Re:Oh no!

[ozmanjusri]

This is the most devastating bug in years.

It could be for Excel users.

65535 is common in computing because it's the highest number which can be represented by an unsigned 16 bit binary. If Excel is mishandling it somewhere in the background, chances are that failure will show up at multiple points.

If I had an important Excel 2007 spreadsheet, I'd be loading it up in OOo Calc or an older version of Excel now.

Re:Oh no!

[Slightly Askew]

As a general rule, if you're going to call someone out in public, it's best to check and make sure you're not retarded first.

I checked [wikipedia.org], I'm not.

Re:

[bockelboy]

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.

Re:Good Luck!

[ross.w]

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.

Re:Good Luck!

[AJWM]

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?

Re:Good Luck!

[teh moges]

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.

Re:

[SnowZero]

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

Re:Good Luck!

[bmo]

"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

Re:Oblig.

[Stealth Potato]

The number 65,536 is an awkward figure to everyone except a hacker, who recognizes it more readily than his own mother's date of birth

Oh god. I never even realized until this very moment that this was true. I feel like a horrible person. ;_;

Re:obviously malicious

[Cassius Corodes]

Never attribute to malice what can be adequately explained by incompetence.

Re:obviously malicious

[Belacgod]

Sufficiently advanced incompetence is indistinguishable from malice.

Re:

[megaditto]

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

Re:

[Mr2001]

RK numbers in Excel [softhelp.ru]. They're not quite how you described them, though. It's a 32-bit value that can hold a 30-bit floating point number or a 30-bit integer (the last 2 bits are for the type), and if a number can't be represented either way, Excel will save it as a 64-bit IEEE float.

Re:Dunno...

[Ford Prefect]

My copy of excel 200 on Win2k gave the correct result.

What, lxvDXXXV?

(And yes, what have the Romans ever done for us, apart from apparently producing correctly functioning spreadsheet software?)

Re:But the important question is..

[Tablizer]

Does the built-in flight simulator still work?

As long as you stay below 65535 feet.
     

Re:So?

[eggfoolr]

Was it not Bill himself who said you would never need more than 64K of memory? Well it's official, you don't need any number greater than 64K either!

Just remember Micro$oft knows best... move along, nothing to see here.