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."
They will be disabling multiplication in all future versions of Excel.
Perhaps this is how multiplication is done in OOXML. They do leap years in dates wrong, too.
What happens if you use this on an older Intel chip? Do the issues cancel out?
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
I bought a Dell this year, it came with Office 2003.
How we know is more important than what we know.
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.
Make SELinux enforcing again!
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.
It's close enough for non-technical users, what's the fuss?
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
http://www.netjeff.com/humor/item.cgi?file=PentiumJokes
My other OS is the MCP!
To all people in science and engineering (I know lots of them) using Excel to analyze their data...
Open a Google Docs spreadsheet. Type =COMBIN(55,27)
-- Subvert the dominant paradigm. Repeat as desired. http://ownlifeful.com/
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....
Who really needs the rest of those numbers between 65,535 and 100,000 anyway. If I can't count something on my 65,534 fingers, I just don't bother.
Try =6*9.
It's used in the algorithm that MS uses to report Vista sales.
Hmm... I guess MIT has a valid excuse for screwing up their SAT Math scores...
Sounds like something intentionally put in for The DoD budget.
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
This just in: Florida plans to do use Microsoft Excel to calculate the 08 election results.
News at 11
Make SELinux enforcing again!
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.
All about me
I literally don't know ANYONE who does any math, whatsoever, in Excel.
It's all tables and primitive databases. The guy in the next cube does some pretty graphs. That's as close as it gets.
The preferred solution is to not have a problem.
Nobody at Microsoft is actually allowed to use the number 65,535, lest Steve Ballmer come and rain fiery chairs down upon them.
(Should I have gone with the "MacBeth/Scottish Play" reference instead?)
- RG>
Hey pal, this isn't a pleasantforest, so don't waste my time with pleasantries!
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.
=850*77.1
</MultiplyLikeExcel2007>
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).
So....now that Microsoft can't get ISO approval for OOXML, they've gone straight for an amendment to basic mathematics specs? :D
This space left intentionally blank.
I have excel 2007 on XP, and I get the 100,000
result. My copy of excel 200 on Win2k gave the
correct result.
emt 377 emt 4
I doubt the same bug occurs, but does anyone evaluate how OO.org fares in math flaws? I suspect some people hold OO.org to a lower standard than one should otherwise expect.
Granted, the above bug looks like a rounding error gone horribly, horribly, incredibly horribly wrong.
I Browse at +4 Flamebait
Open Source Sysadmin
RK numbers in Excel. 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.
Visual IRC: Fast. Powerful. Free.
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
Maybe someone figured out a way to use Excel 2003 as a platform for audio/video capture and it too was "fixed" to please the content industry? ;^)
--
Toro
Never attribute to incompetence what can be adequately explained by malice.
Can we move on now? It's completely possible to point out that microsoft is capable of extreme incompetence without repeating this nonsense.
The Farewell Tour II
If an application can cause a kernel fault, it's not only the application that is broken.
There, fixed that for you.
-- Alastair
Did you even read the title of the summary?
I always said that Microsoft would never successfully migrate from 16 to 32 bits...
Parity: What to do when the weekend comes.
Sufficiently advanced incompetence is indistinguishable from malice.
That explains why OOXML can't be an ISO standard, it evaluates 65525 = 100000
just wonder why there are so many anonymous cowards in this world....
What, lxvDXXXV?
(And yes, what have the Romans ever done for us, apart from apparently producing correctly functioning spreadsheet software?)
Tedious Bloggy Stuff - hooray?
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
Does the built-in flight simulator still work?
(Yeah, I know, they took it out after Excel 97.)
-- Alastair
The bug shows up for me. I'm running on Vista, and my About box gives the Excel version as 12.0.6024.5000 (MSO 12.0.6017.5000).
That was 6 minutes after your post, my time. It's been 20 minutes already! Where's my news!?
Math is hard.
Let's go shopping
What?
Uhhh no.
The application simply should not be able to cause a kernel fault.
Period.
I'm sure this happens at Microsoft. A bug gets reported that Excel 2007 is causing blue screens. The bug gets given to the Excel team, they look at the crash dump and find out that they are doing something that trips a bug in the kernel of Vista, and they change their code to work around the issue. Bug closed. Next time someone runs across the exact same issue, they do a workaround too. The bug in the kernel never gets fixed.
How we know is more important than what we know.
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.
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.
;p).
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
They don't have excel 2007 for the mac
This is just the new proprietary numeric system. While the rest of the use use base2, 8, 16, or 10 Microsoft operate on baseMS. The 100,000 baseMS (65,535 base10) page white paper is forthcoming.
I think the invisible hand of the market has its middle finger extended
--A wise old fart named SC0RN
It looks like someone managed an off-by-one error in it, with this as the result. Well, it's not like anyone uses Excel where errors could have serious consequences, right?
Lacking <sarcasm> tags,
Corollary: Any incompetence distinguishable from malice is not sufficiently advanced.
Civil Engineers only use Excel in Minnesota.
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.
http://img443.imageshack.us/img443/6650/exceldy7.png
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
MSOffice doesn't run on the operating system, it runs the operating system.
Lacking <sarcasm> tags,
This is an example of that new Quality stuff that Microsoft just invented. This new Quality thing is sooo cooool that it removes the need for any kind of regression testing. We can look forward to more Quality in the future from Microsoft as they decide to not bother testing more and more of their products.
Now how can I work this into my salary.......
These are some of the things molecules do...... given 4 billion years -Carl Sagan
Excel still had a 65K row limit, which was very annoying. Whenever we generated detail reports for Excel users we had to break things up into sub-files which often introduced all sorts of errors as people manually combined the results from separate sheets. I never understood why they would have such a limit in place. Using a 16 bit number for most anything in modern apps seems a bit foolish.
I sort of get the idea that if you need more than 65K rows then you should move up to something else besides Excel, but still. It just seemed that the business users always asked for reports that were larger than Excel could handle, then they'd have trouble with them.
Cheers.
Office 2K7 on XP SP2 and I see the same results as the article.
It's broken here -- WinXP SP2, MS Office 2007 (Excel v. 12.0.6024.5000).
I've done a lot of defending of MS for Office 2007, but this is a little scary. Word can suck in spots, but math really has to work.
It is pitch black. You are likely to be eaten by a grue.
To get everyone to upgrade to Excel 2008. Out soon!!!! Lots of new, er, features...cheap!!!
Once I was a four stone apology. Now I am two separate gorillas.
I just checked and, of course, OOo spreadsheet (oocalc) has no problems with the above numbers, they show correctly (eg 40000.2230000000). Excel must have some really funky internal representations and algorithms, I'm surprised they didn't include a <CalculateLikeExcel> tag in MS-OOXML.
-- Alastair
While this is true, I'd bet that the reason Excel is having problems is because it's doing all that weird stuff (like what's with that UI?) and possibly using newer/undocumented API calls.
It's inexcusable, but understandable, since the Office apps are most likely first-adopters of new API calls.
Buckle your ROFL belt, we're in for some LOLs.
a 16-bit application at heart. All the development done since Version 4 is more or less window-dressing (or fabulous new features).
It also cannot display more than 2**16-1 lines in a table; that seems to be regarded as a feature, not a bug.
I can assure you, the best way to get rid of dragons is to have one of your own.
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.
"I've got more toys than Teruhisa Kitahara."
Excel has a bug, just like every other tool. Some people report not being able to replicated the bug in their version of 2007, it doesn't matter. Assuming there's a true bug somewhere, it will be fixed - life goes on as usual. What's the story exactly?
In other news, the IPCC has issued a statement saying that its original estimates for global warming were miscalculated and were "approximately double" the corrected estimates due to a "technical issue".
www.shortman.com.au - top shorted stocks on the ASX
So this is how they calculated sales for Vista!
I see I screwed up by quoting 2003 edition but in his case, he's claiming it's fine with 2007 ..... inconsistent results it seems.
Give them a break... they were too busy programming that stupid ribbon, and shuffling all of the options around to confound advanced users.
-Tom
Is it just me or does it seem like there's probably a hidden cheat code somehow related to this. You know, like, plug in the mystery number and Windows stops freezing up on you?
FWIW all, I just tried this on my G5 with both Excel 2004 and NeoOffice and both calculated correctly.
:-)
Mayhaps the MacIntrash (as some are fond of calling it) ain't so bad after all!
Then again, it *did* spawn a copy of Word with Clippy bouncing around the screen "like a Jack Russel Terrier" asking if I wanted it to throw a chair across the room on my behalf. I'm not so sure this was intended, especially from such a simple formula, regardless of any so-called calculation bugs.
Besides which, I wonder where Clippy would even get such an inclination.
Running 'Nix is like owning a Lightsaber. It's "a more elegant weapon for a more civilized time."
I think we should all tag this story OOPSXML. :^)
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.
Someone left an "0x" off of a 100 somewhere. I'm trying to imagine the most likely scenario.
Maybe this is a clue:
Dear Slashdotters,
Our recent feature in Excel is not an annoyance; but the first page in a new chapter in humanity. We have had the best minds from MENSA working on this concept for years. We don't need to rethink Excel as much as we need to rethink numbers.
This forward thinking will usher-in a new dawn for the human race. Numbers between 100,000 and 65,535 are relegated to superfluity. Join us in making this new number system a success!
Your Friend in Redmond,
William Gates III
The game.
now why would that be? oh right, we can't have backwards compatibility, that would allow competition. [just kidding] but really, what was the reason for changing the way excel evaluates a function? what did that change actually improve?
MS significantly jacked up the number of rows and columns in Excel, and they might have gone from a sparse matrix to a tree as an internal storage. That would entail a change in how the interpreter works.
This is my sig.
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
I've just tried and Mac Excel 2007 (v 11.3.3, build 061213) calculates the values correctly. One more bonus for OS X! ;)
Attitudes make the difference between Space and Time: we want to MAX our temporal, and MIN our spatial extension.
Who needs to count over 640, anyway?
If anyone really does, there's always the HIMEM.SYS and EMM386.EXE plugins.
And you didn't balk at the 34% increase in rent?
This issue is a bit more complicated than you think.
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
Guess I'm the only one left who uses CAD to make network drawings nowadays?
It's very interesting, because whenever I run unit tests, even more important than randomized testing is the edge cases. In this case, the numbers they should be running through all their functions would be (for short) -65536 -65535 -257 -256 -255 -2 -1 0 1 254 255 256 65534 65535. That right there catches 95% of the errors for the standard operations (+,-,*,/). I couldn't imagine not running those tests for a numeric library. It's just .... stupid.
To go from 65535 to 100000 ... I dunno. Maybe a weird string conversion error? I can't see it be a casting error of any sort, 100000 just isn't a number that's naturally represented on a computer in any way.
Actually, if I had to guess, I'd say rounding error combined with overflow, or maybe negative numbers. abs(-65536 * -1) = 1. Substitute * for /, or 100000 for 0.000001... who knows.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
My first guess is it's the result of some optimization that went wrong. In any case, it's got to be pretty darn embarrassing for a spreadsheet application.
That's odd. Same set-up here. Must be a version thing.
If you want news from today, you have to come back tomorrow.
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: It happens to be a power of 2^16 power to be exact -- and even the exponent 16 is equal to 2, and 4 is equal to 22. Along with 256; 32,768; and 2,147,483,648; 65,536 is one of the foundation stones of the hacker universe, in which 2 is the only really important number because that's how many digits a computer can recognize. One of those digits is 0, and the other is 1. Any number that can be created by fetishistically multiplying 2s by each other, and subtracting the occasional 1, will be instantly recognizable to a hacker.
Maybe they convert to base 9.18956?
The problem is that you didn't even read the title. It's Excel 2007.
65,534 ought to be enough for everybody.
Somewhere, Arthur C. Clarke is angry at both of you.
What was once true, is no longer so
As an undergrad the version of Excel that was common at that time (ca. 1996) had a serious flaw in the linear regression. The line fit to data was good, but the formula it output has nothing to do with the line it drew. The intercepts were wrong, slope was wrong, it was like it spit out random numbers. I almost failed p-chem lab because the final calculations relied on the fit to the data and those were wrong. Redid them in an ancient version of kaleidagraph on an ancient mac (then) and got the right numbers and the grade changed. Don't trust Excel!
A few observations:
1) If you go into the Visual Basic editor and print the "Value" property of the cell containing the formula =850*771 you get 65535, as you should. The "Text" property however is "100000". So it seems the problem is not in the internal computation, but in the conversion to the displayed value.
2) That said, I am not sure why, if you then enter =A1+1 into another cell you get 100001 instead of 65536. It seems the formula is picking up the displayed value, not the internal value when you perform addition, but not when you do multiplication.
3) There is something special about the value 77.1. Other variations on the calculation produce the correct result.
85 * 771 = 65535
850 * 77.1 = 100000
8500 * 7.71 = 65535
I wrote a short C program so I could see what the actual floating point representations of these numbers were:
#include
#include
int main (int argc, const char *argv[])
{
if (argc != 3)
{
puts("You must enter two numbers");
}
else
{
double v1 = atof(argv[1]);
double v2 = atof(argv[2]);
double result = v1 * v2;
printf("%f * %f = %f\n", v1, v2, result);
printf("%#016I64x * %#016I64x = %#016I64x\n", *(long long *)&v1, *(long long *)&v2, *(long long *)&result);
}
return 0;
}
This produced:
850.000000 * 77.100000 = 65535.000000
0x408a900000000000 * 0x4053466666666666 = 0x40efffdfffffffff
Notice that the value 77.1 has a repeating fraction when represented in floating point. So does the result. In fact if you dig out your Intel manuals and decipher the hex representation of the result you find that it is the binary equivalent of 65534.99999999999999...
It seems that the problem occurs in the conversion of that value to displayable text.
It must have been a bug instead of white-collar scum!
They're using their grammar skills there.
Well, I'm off to deposit $655.35 less my current balance into my bank account.
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.
I can confirm it on Excel 2007 (12.0.4518.1014), running under Vista.
I bet they put that feature in for selling Vista volume licenses. In bundles of 850 the price is $77.10 each which is $100,000.
If it was funny then why wasn't it modded flamebait, with the GP being modded as insightful, you being modded funny, and myself being modded as being larger than a breadbox?
Just for fun I cranked up Microsoft Multiplan 1.06 from 1983 for the Commmodore 64 (using the Vice emulator, 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.
If you're a zombie and you know it, bite your friend!
My Office2000 version works fine...
I bet my copy has the same features as your well-paid 2007 one minus the bugs and bloat yours has...
And it's got the bug. Running on XP.
So, what's the plan here, is Open office calc going to be implementing this feature too? Well, at least it is proven that closed source programs with big companies behind it have their problems too, who knows how many really serious calculation errors have been made without people knowing about them.
We seem to have made a mistake in his political views. Oops, he died? Thank goodness his number is unlisted.
It's ok, I only run Excel 2007 on my 286.
May contain traces of nut.
Made from the freshest electrons.
It's not a bug, it's a feature. Like OOXML, where all MS defects had to be implemented as features by other developers. MS has defined this MUL as a feature. It is now up to us to update textbooks and other spreadsheets with the same feature.
don't cut it off www.mgmbill.org
...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 and prnum16.asm
--JoeProgram Intellivision!
Comment removed based on user account deletion
why, what, how?
I know 65535... it was called a WORD back in the old days (16-bit). (And a WORD is an unsigned INTEGER).
All of the sudden if anybody just 'knows' stuff it is because he read in on an overhyped wiki?
It must be bunnies!
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
For that matter, ask Google how may radians in a cycle. Do No Evil Inc. hasn't bothered to fix that in the year or so since it was reported to them.
...everything is peachy! Now THAT is backward compatibility!
Alas I do not have windows - be woudl be a good test case.
I've heard the word before, obviously, but never in relation to Microsoft software, so it must have some other meaning in this context...
That is a very Spreadsheet-like mentality.
A mentality of not wanting to learn a programming language, so you learn Excel, which really isn't any easier, and is, in fact, considerably harder when it comes to doing anything complex. But like the idiots who learn PHP, you stick with it because it's what you learned on, even once it's painfully obvious (even to you) that you've got an unmaintainable mess.
Don't thank God, thank a doctor!
What's your point?
*dramatically* ooooh, whats the point!
here i am, having the greatest table ever created, and what are they using it for?
tower calculations!
It never finishes the calculation, hence never gets it wrong?
www.aleo.no
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
http://digg.com/microsoft/Critical_Excel_2007_bug_cripples_users
They are using floating point number for multiplication of non integer numbers (unless I missed something one of the number he multiply to as ".1"). The Intermediate number of the calculation must be a floating point and THEN a floating-point-to-integer conversion happens because it sees "ohhhh I can convert this because the fractional part is .0000000000000 (i.e. all bit set to zero)". This only point to some weird behavior of the floating point to integer conversion, but not of the multiplication itself. Still this is a big one... I'll try it at work for a laugh.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Brought peace (on the desktop)?
I've just tried modulo on the formula result, and it appears that Excel 2007 just goes STARK RAVING MAD.
Assuming A1 is =850*77.1
MOD(A1,65534) returns 1 (A1 is 65535)
MOD(A1,65535) returns -7.27595761418343 * 10 ^ -12
In fact, where the divisor is from 1 to 65535, where the modulo would normally return 0, it returns this tiny decimal value.
MOD(A1,65536) returns 100000. ??
Where the divisor is 65536 or greater, the modulo goes mad and just returns 100000.
Even MOD(A1,100000) returns 100000, when that should be impossible with a divisor of 100000.
Conclusion: Microsoft accounted their Vista adoption rate using Excel 2007.
- xuanyou
I think the flawed decisions people make based on Excel sheets are now cancelled out by flawed Excel sheets, making for good decisions.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Excel 2003 has 65,536 rows. one number off ... Coincidence?
What's the logic for selection of this amount of row limitation?
What's the significance of this number to Excel?
I'm going back to calc.
(Yes I have tested it. Perhaps they should open up it's API to Excel).
And I thought I was the only one doing that ! Most people in my department use Excel for graphs, filtering and other tasks that Matlab is so much more suited for. I'm one of the two people actually using Matlab.
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!
What's in a sig?
The lameness filter is set to reverse. It rejects useful code and ascii art.
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
it wouldn't be their first fukked-up decision though, would it?
Now we know how they came up with all that Global Warming data!!!
It is not hard to write a working spreadsheet. You need to deal with the issue of updates that cause more updates (i.e. non- or slow-converging speadsehets), sure. But it is understaood how to do that: Limite the cycles, detect loops and warn the user.
Apart from that, it seems to me it realy takes a very high level of incompetence to screw up direct computations. I don't think anybody besides Microsoft manages to be this stupid. And in a mission-critical application, no less.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
While it's true that one can't ever find all bugs, and some bugs will occur in surprising places...for a skilled test engineer, testing the boundaries between 16-bit and 32-bit integers is a pretty straightforward area to cover.
There is just no way that you are the pine-scented air.
I think you're onto something. The discrepancy with 'A1+1' is most likely to do with the addition operator for text fields taking precedence and ignoring the value field, where multiplication is not defined for text fields and doesn't get messed up by precedence rules. Still, how the value to text field conversion of 65535==100000 came about is mind-boggling.
Great! Maybe the results will be more accurate than last time!
Maybe it's a Visual Studio 8 compiler bug. Between Excel 2003 and 2007, Microsoft released Visual Studio 8.
/arch:sse. Someone claimed here that on a Pentium Pro it works correctly, suggesting that it could be something related to SSE. Mac Excel 2007 doesn't have the bug, but that is probably compiled with ICC or GCC.
It'll be fun to reverse engineer the patch they'll release and see what the problem actually was. If it's a compiler bug, it would be best for all developers to know.
It wouldn't surprise me if it were a bug in the code generation for
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
while I recon your refference to the excellent Pyton's "Life of Brian", I think you should definitely watch one of the Pyton's cast series, the Terry Jones' Barbarians to know what Romans did for the world.
16 bits should be enough for everybody...
We often refuse to accept an idea merely because the tone of voice in which it has been expressed is unsympathetic to us
That would be Office 2.7K moron
Rocket science is easy. Neurosurgery, now *that's* difficult.
... 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?
That's all fine and dandy, but where is the prnum64.asm? ;)
Uh, actually the hourglass has already made a quarter turn since last night, so it's making progresses ! ;)
May contain traces of nut.
Made from the freshest electrons.
Just to back that up, compadre, 8bits=byte, 2bytes=word, 4bytes=longword, 8bytes=quadword, 16bytes=paragraph, 256bytes=page, 256pages=64k. Thus the two 8bit x/y addressing registers of a 6502 could address 65536 memory locations. It was pretty good to know that for bit-shifting to get to memory quickly in assembly. Further, the PDP-8 and HP-1000 were both word-addressable, not byte addressable machines and if you used them for data acquistion (common to do in those days, load naked asm from another machine), you used words for your 16bit i/o DACs.
.... no, wait .....
Here - let me sim that in Excel for you
Pathological kinda promises Path + Logical - but instead, you get stuck with pathetic.
From somewhere in the code storage section, an evil laugh can be heard...
"Fire ME will you? Hahahaha. Looks like you're trying to resolve a 16 bit number do you want:
* The correct answer
* 100,000"
Seven puppies were harmed during the making of this post.
Which, in standard electronics speak is 2K7
"This behaviour is by design."
By definition, 1 Hz = 1/s and 1 rad = 1. I follows that 1 Hz = 1 rad/s.
The problem is of course in the semantics. There's nothing in the definition of a hertz that limits it to cycles or rotations. So Google's answer is among the infinity of possible interpretations. If an object turning at 1 rad/s beeps at every completed radian, the beep rate is 1 Hz.
By the same vein, Google correctly reports that
1 radian = 1.66053886 x 10^-24 moles
Anyone knows when this will be in OpenOffice? (The manager would be so reassured.)
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Unfortunately I see more and more software companies using beta testers where they should've implemented quality control from the start. In a properly designed program, you can pretty much point at any sort of calculation or procedure that might cause off-by-one errors and such.
Having more people at least look over the code for these kind of discrepancies saves a lot of headaches later on.
Coz eternity my friend, is a long *ing time.
So that's how...Bill got to be a billionaire?
... $65,535 $100.000 ... $655,350 $1,000,000 ... $65,535,000 $100,000,000 ...
He couldn't count: $1 $2 $3 $4
He is really only 2/3 as rich as he says he is!
I am anarch of all I survey.
Its all good to document the bugs, but will the product manager approve the fixing of such bugs, if his personal stats on number of bugs
found/fixed is high, and he loses his xmas bonus. He might just reclassify it as a 'low priority' low impact bug and put it on the bottom of the other
500000 bugs.
Just like IE6, MS has recognized lots of bugs, some simple that would take one line of code fix, but would NOT DO IT, because they had
top orders to do security ONLY fixes.
Sometimes you gota just say, "screw you management", we are fixing any bug that is quicker/shorter to fix than it takes time to sip a coffee.
Liberty freedom are no1, not dicks in suits.
No wonder you can't meet any women!
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.
8 bits = byte but bytes have ranged from five to twelve bits.....
Puteulanus fenestra mortis
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
what is that? machine code? (cpu?)
I work for the Department of Redundancy Department.
It's a magic number.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
When you enter a value in a cell, it should start the auto-detection from scratch. Instead, it takes the decimal number and try to interpret it into a date, despite that the format used is obviously not a date format, and your cell is defined as "standard" format cell. The fact is, if you enter directly the 3,4 (, is used for floating "point" number) in a cell which was empty it correctly interpret it as 3,4 and not as 3rd January. Only in case you had a date previously in the cell it put 3rd January.
"English or Swedish date formats might cause trouble in German" there are specific format saved in windows configuration panel (regional coding) and it ignores the regional coding. Another bug.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
....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...
I would have to say that explosives are the most abused technology in all of history.
.
.
.
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
Are there any spreadsheets/methods that are available for download that would do a good job of running large test cases on Excel? With the amount of companies running this for sales projections, marketing, stock price trending, etc. a large portion of the economy is dependent on the accuracy of Excel and other mathematical software.
I'm not a Programmer, but I'm getting the impression that MS's test cases weren't extensive enough to pick this one up. Do Sys admins or end-users have test case spreadsheets before installing patches or new versions of Excel to ensure that the results of the new version of Excel or patched version gives the same results as previous versions? And were those the correct numbers?
I've wondered too, are there chances that different CPUs (hardware or compiler bugs) generate different results for the same equation?
It was announced that the problem will be resolved by submitting a new standard to the ISO committee for fast track:
2.15.3.6 multiplyLikeExcel2007 (Emulate Excel 2007 multiplication product output.)
The * operation, previously known as "multiply" has been overloaded^H^H^H^H replaced with a new operation which will be known as multiply. A description of this function shall emulate the behavior of a previously existing word processing application (Microsoft Excel 2007) when determining the function output of values near 65535, the resulting output (also known as "product" shall behave identically to Excell 2007. [Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors (random, psychotic or otherwise) and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications (perhaps using a table or random number generator.) It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]
Yes and no, the definition of a WORD has typically been hardware specific. For example, on a PDP, a word was 18 bits, IIRC. However, it has always meant a bit-field, which doesn't make any assumption about type.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
"We have processes in place now where we build documented-threat models at design time .."
.. Good think this integrated innovated professional software product isn't written to the same standards as that amateur Linux rubbish made in some kids bedroom ..
How about hiring someone who can count
davecb5620@gmail.com
Only if we could all pull information from wikipedia and call it our own. At least give credit to where you got your information from.
Yes, that's right. Nobody here would have known why 65,535 was an important number without looking it up on Wikipedia.
Please mod parent back up so that everyone can witness what must be one of the biggest own goals in Slashdot history. 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'm sure the bug has to do with some kind of confusion over 65535 as a string and that number topping out the number of lines, so when that number comes up as a sum, the bad code in Excel sees it as a line value and kicks out something with a pile of zeros, like 100,000.
Some programmer just got his wings clipped for that.
It makes the baby Jesus cry.
RS
Shoes for Industry. Shoes for the Dead.
I checked, I'm not.
Public use of any portable music system is a virtually guaranteed indicator of sociopathic tendencies. -- Zoso
Here's my question: why is the maximum 16 bit unsigned value significant in the first place? Excel runs under Windows, and Windows runs on 32 bit processors. It seems improbable that new code would have bugs like this. Did they link in old 16 bit functions by mistake?
Hmmm. How old are you, number 90981 and what do you do and what are you doing on /.? Ever programmed in Assembler or have done any computational analysis whatsoever?
Check this out, 0x20 (that's hex) is 32 decimal, it is the number used in ASCII to represent a single space.
And I didn't even have to use LeetKey for it.
You can't handle the truth.
Imagine a Beowulf Cluster running Excel 2007!
I for one, welcome our Excel 2007 bug Overlords!
Does it run Linux?
In Russia Excel 2007 bugs YOU!
umm.... Is that it?
Don't be apathetic. Procrastinate!
Hey Mr. Holier-Than-Thou, I got Office 2007 for the low low price of having to leave three Microsoft web-seminar videos running on my computer while I did other things. At the end of that they sent me a free copy of the suite.
Whew....if I was the breadboard and resistor type of geek I'd be worried about my apparent abreviation faux-pas.
I need to make sure I bill in minutes and charge $77.10 for each. Come on lucky 850! Come on lucky 850!
Armaments, 2-9-21 And Saint Attila raised the hand grenade up on high, saying, 'O Lord, bless this Thy hand grenade' N
I suppose they could use BCD, but you're going to have to convert to IEEE floating point to run it through the processor anyway. You could just use a higher precision type internally and only display a lower precision, but either way OOCalc is still lying to you about what that number really is.
Unless they do BCD computation in software, of course. That would make OOCalc way more slow and bloated than it already is though.
I believe this specific feature is on page 4,357 of the Microsoft OOXML spec, paragraph 2. Anyone that implements the OOXML spec must calculate the same way.
Fired up Excel 2003. Typed in to A1: "=850*77,1". Got 65535. What am I doing wrong?
2003 != 2007
Note to self: learn to read.
65535 is common in computing because it's the highest number which can be represented by an unsigned 16 bit binary.
Ohhhhhhhhh... so THAT's why I can never get my super top secret web server to run on port 75,000.
Next you'll be telling me that the sky is blue.
Just disrupt the deflector shield with a tachyon burst.
Wow, that was a lot of work to demonstrate that a number ending in a 5 isn't prime.
I read the internet for the articles.
Who, there, ceyoyo!
First, a BCD arbitrary precision math package weighs in at around 8K bytes (binary estimation for x86).
Second, the OOcalc approach can be reviewed (I haven't bothered).
Third, these numbers can be represented in an exact format without the mess of BCD (scaled integers). If I were writing a program used by accountants, I would use scaled integers of arbitrary length. I would only convert into floating point when a transendential function is used. I would also use rational numbers as much as possible (after all 1/3*3 should be 1, yes?).
Fourth, there are systems that use these approaches to great success (and no one calls them "bloated"); I give you Smalltalk (Squeak), and the number stack in Scheme.
Again, I HAVEN'T reviewed OOCalc (because I honestly don't use it), but the software I *do* use for basic math doesn't suffer from these issues because it can't (by design).
Are you telling me that a math system for ordinary people DOES suffer from these issues (specifically, Excel)? People who use the computer without knowledge of the limitations and characteristics of floating point numbers? And who possibly depend on the correctness of the answers? Now, heres another thing - if the person uses a pocket calculator, 1/3 is either IMMEDIATELY displayed as "0.3333.." to the limit of the display, or is (in some calculators) kept as 1/3. But the effect is exposed. If 1/2 is calculated, the answer is exact in either case, and a chain calculation (*2) works as expected. But with a spread sheet, a conversion between the two can happen with the user seeing it!
I find it mind-boggling. Maybe I should crank out a simple Scheme based spreadsheet. Perhaps call it "AccurateAnswers", or "CalculatesForSure".
Excel is wrong. Possibly OOCalc is wrong (I don't know). Please hold peoples toes over the fire until it is right.
Just another "Cubible(sic) Joe" 2 17 3061
I don't agree with the nomenclature used in the Wikipedia article. I believe Tiger is properly written "OS X 10.4" not "OS X v10.4".
It's true that the "X" and the "10" are redundant, so in conversation I would say "Oh ess ten point four" or "Tiger". It's just one of those cases where how you spell something and how you pronounce it are a little different.
I don't expect Apple to release OS 11.0 anytime soon. That would imply a huge change from the 10.x series, at least as big as X from 9. If they do maybe they'll do a play on Roman numerals and Greek letters and call it OS , OS or OS Xi. (Damn that's hard to make work in HTML.)
But I'm using a first gen Pentium 1, I guess they cancel each other out?
(joking)
Returned Peace Corps IT Volunteer
Seriously, what can we expect from a bunch of code monkeys. Wow, so those mainframes used on banks running J2EE are doing all calculations wrong.
Man, hate Java or troll but really try to make a minimum sense OK?
Please, this is a bug, but it's a display bug. As several posters
have pointed out, you can manipulate this value all you want (graph,
input it to any function), and it is treated as 65535.
It matters for reading these numbers as symbols, on screen or in
print. How often would one come across this precisely calculated
number, in a cell that is intended to be read by human eyes? You're
more likely to be struck by lightning.
"I have approximate answers and possible beliefs and different degrees of certainty about different things." -R.P.Feynma
Because I'm an accountant, whether I want to or not, I've had to become fairly expert in Excel. The "currency" data type from excel is supposed to prevent this. I don't believe it, and haven't tried it. Excel likes to do too much sneaky polymorphic data manipulation unless you nail absolutely everything to the floor for any reliance on data-typing IN THE SPREADSHEET to be reliable. VBA code might theoretically be different, but there are whole boatloads of other reasons why it's a dumb idea there.
However, wrapping your calculation in round() will solve your problem. As others have said, this is a floating-point thing, not an evil-Microsoft thing. Instead of your bare formula, use =round([formula],[digits 'o precision]). Hey presto, no more floating point problems.
Do not taunt Happy Fun Ball
If Excel is bluescreening your machine you have problems that go far beyond office. I assume you're using XP in this case. Either you have a MAJOR problem with your Windows install, you have a bad driver or your hardware is failing. Take your pick.
I'll bet that even this machine would have gotten it right.
"How to Do Nothing," kids activities, back in print!
I would honestly be really surprised if Excel used undocumented APIs. That would be inviting a lawsuit. Anyways Microsoft doesn't exactly hide when they do such things (IE, Windows Media Player, Search) because they don't see a problem with them.
BorkedMultiplicationLikeInExcel2007
Want to hear the voice of GOD? cat
Perhaps this is the way to get fabulous Vista sales figures?
Take Nobody's Word For It.
Let me say it again for good measure.
"What in the name of Fats Waller is that?"
"A four-foot prune."
My first thought was internally they are not doing real floating point math, but multi-precision integer math or some flavor of BCD. Since this is a magic number for 32bit integers, it would seem the multi-precision integer functions might have an issue.
That sounds like it's not a programming bug, but more of a logic bug instead.
Don't be apathetic. Procrastinate!
Not a conspiracy! Ha! Who do you think came up with IEEE 754?! Hint: It certainly wasn't Linus Torvalds or Steve Jobs!
WORD size is dependent on architure.. On my 32 bit laptop a word is 32 bit.
and 65535 isn't a word. It is just the largest unsigned integer you can represent with 16 bit.
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.
Where are the more creative modpoint options when you need them...
And don't forget, kiddies, big important people have been known to select Windows software to do such things as run naval destroyers. So outfit your bunker, pop open a beer, and sit back to watch the show!
< ...shudder... />
"What in the name of Fats Waller is that?"
"A four-foot prune."
I also demonstrates that the GP thinks one can generate prime numbers using an integer overflow.
Want to hear the voice of GOD? cat
Since when is there scientific math vs all other math? I must have been out when they explained math segregation while studying for my mathematics degree. I do recall something about economics and buying the cheapest product that meets a need. Don't recall scientific being an independent variable there either.
The world is made by those who show up for the job.
There's nothing "wrong" about it, it's a side effect of changing bases and it just means you can't depend on the last digit or so of precision. If you need those digits, switch to a bigger type.
Scientific computation uses IEEE floating point pretty much exclusively. You just round off the last digit or so. As you point out, calculators do the same thing. If you're depending on the least significant digit of your data type to be precise, no matter what base, accountant or not, you really shouldn't be working with numbers.
I forgot about using fixed point math, which you could do, but again, it's a software solution that's going to slow things down. It might be okay for a spreadsheet but it's a no go in many other applications. Do you see anyone using Scheme or Smalltalk for heavy number crunching?
Neither Excel nor OOCalc is wrong. The most likely answer (I don't have time to dig through the OOCalc code to find out for sure either) is that OOCalc is rounding that least significant digit for you. Excel isn't but you SHOULD be when you look at it.
If your accountant doesn't know about significant digits, switch accountants.
That the wrong result is 100,000 even is mighty suspicious, too.
I wonder if, internally, different chunks of code are fighting over whether to truly convert to floating point or not. Something sees "77.1" and says, "sure!", while another says, wait, if we multiply it out, it is not really a floating point.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Are you suggesting he'll never be one of those math wizards who can perform seemingly mysterous feats of calculation in their heads?
Jeebus H. Christ! You determined 65535 wasn't prime in a fraction of a second. My Gott in Himmel.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Office 2.7K "moron"? Is that the next version?
To be, or not to be: isn't that quite logical, Slashdot Beta?
Any malice distinguishable from incompetence is insufficiently advanced.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
You show me how to represent 0.1 with perfect accuracy in floating point, and I'll write you a new spreadsheet app that doesn't need to fudge numbers. .Net (and I think SQL Server) that wouldn't have that problem; as long as Excel displays numbers as decimal, it should be computing them as decimal.
It's easy as long as you don't insist on using the wrong base. Microsoft has a 96-bit decimal floating point type (32 bit exponent, 64 bit mantissa) in
I misread the newsgroup and thought that the message saying "2003 too" was saying that it had the bug, not seeing that it was a response to a message saying that Excel 2000 *did* work.
FWIW, it may be related to this old bug.
I just entered =850*77.1 into OpenOffice.org, and it gets the correct answer. It's rediculous that a freely-available program can get basic calculations correct, and Excel can't.
- David A. Wheeler (see my Secure Programming HOWTO)
Microsoft: "We are aware of this bug and have promoted it to the highest priority in our maintenance database.....which we keep in Excel....(Oh crap!)."
Have gnu, will travel.
Results 1 - 20 of about 745,000 for "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0"
First hit:
That's the so-called "Processing Key" that unlocks the heart of every HD-DVD disk to date. Happy Valentine's day, AACS. AACS, a DRM scheme used to encrypt data on HD-DVD and Blu-Ray disks, would appear to be cracked wide open by that short string of hexadecimal codes
The MPAA sent out a ton of DMCA take-down notices attempting to censor that number, but of course "Results 1 - 20 of about 745,000" just demonstrates the stupidity of even attempting to censor a number (or anything else) trying to get DRM to work. Not to mention another 418,000 hits for "09F911029D74E35BD84156C5635688C0" and a few thousand hits for the decimal version 13256278887989457651018865901401704640.
That number is arguably a criminal circumvention device under the DMCA, and it is potentially "criminal trafficking" for you to tell that number to anyone.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
You sir, have earned a cigar - a byte was once the addressable unit / accumulator unit of a machine, before 8 bits became the packet of choice. We wax nostalgic....
Pathological kinda promises Path + Logical - but instead, you get stuck with pathetic.
Why doesn't it do this with, for example, =65535*1, =131070*0.5, or =32768*2-1 ?
Terrorists can attack freedom, but only Congress can destroy it.
That should be lxviDXXXvi
emt 377 emt 4
And what happens when you run it on a Pentium with the FDIV bug?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Since in Excel 2002 at least, DEC2BIN can only handle 9-bits, so anything over 511 borks to #NUM! and BIN2DEC(1111111111) returns -1.
WTF?
Excell has had multple bugs throughout the years. Some flaws have been pointed out by the statistics community in some papers and online publications. Issues in umercal stability and random number generation, for instance.
What's particularly troublesome is that some medical doctors and other members of the health community/industry actually use Excell (although, it has to be said, those not particularly well-acquainted with statistics). OTOH, you;d be hard pressed to find any professional statistician using Excell on any data.
Some people just assume that if Microsoft's behind the product, expertise is garanteed. Which, as we know from the MS track record in their main area - operating systems - is simply not true.
But a multiplication bug tops it all!
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
What's your point? 6*9=42 (in base 13...)
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I would say perl or python. Learn ruby to learn its elegance, but stay away, the performance is probably too high a price, and once you get to know it, it's just as quirky as the other two.
.php files that contain almost no HTML, and are essentially one gigantic php tag. It's become more the other way around -- you can embed HTML in your PHP, if you need to.
Or really anything...
Here's why PHP is for idiots: It started out as a language for people who knew HTML, and wanted to add a little server-side stuff, without learning a server-side programming language. So they learned to sprinkle things like this:
<ul>
<?php for ($i=0; $i<10; $i++) { ?>
<li> Value of i is <?php print $i ?>.</li>
<?php } ?>
</ul>
throughout their websites. All kinds of things -- hit counters, etc. Webcomics are another great target for PHP -- basically, you write an HTML template page, and just add a few little php tags for things like the img source, and if you're very clever, to pull a comment from a database.
Basically, PHP was meant to be embedded in HTML pages, not to be a full-fledged language in its own right. It also looks like it was meant to feel like Perl.
But, they added more and more features, and people, more and more, began to realize that separating logic from content from presentation is a good idea, so sprinkling PHP tags throughout your HTML isn't the way to go. So there are now plenty of
That is the one strength of PHP. Well, one of several. Another, for example, is taking the results of a form submission and making them local variables -- which is a fucking huge security hazard, and no serious PHP programmers have that turned on anymore.
As a language, they basically took some Perl syntax and made a language that is otherwise somewhere between C and Java in terms of functionality. It has object-orientedness, but only in the most recent version, and it's broken as hell. I'm not sure if they even have function pointers, or pointers at all. It's all the functionality of Visual Basic, but with the clean, easy to use syntax of Perl!
It is possible to write amazingly good programs in PHP, but that's despite the language, not because of it. PHP offers absolutely no advantage over any other scripting language, except that it's installed by default. Even the ability to embed HTML in PHP (or vice versa) isn't new -- you can embed Perl in HTML with special server-side extensions, but even standard Perl makes it easy to print super-huge, free-form strings, so if you really want to, you can stick HTML into your Perl.
Which means the only advantage of PHP is its ubiquity. So it's kind of like Windows or Visual Basic in that respect, but if you have the freedom to choose your environment, you'd have to be an idiot to start with PHP. The only reason I can see choosing it is legacy -- for example, if you have a project that was always PHP, and you don't have the time to rewrite it, or if you want to start with Drupal or something.
Don't thank God, thank a doctor!
65535 in A1
1 to 65535 in B
D[foo] = A1 / B[foo]
E[foo] = B[foo] * D[foo]
Many rows have a value of 100000.
13,26,49,52,81,87,93,98,104,107,115,117,118,123,162,169,173,174,186,196,...
Slow things down? Why?
Keeping a rational object 1/3 is as simple as
object: numerator=1 demonimator=2
Both are simple integers.
When adding 1/3 + 1/3 + 1/3, the computer needs to do 4 integer adds.
If 1/3 becomes 0.333.., the computer needs to do 2 floating adds. Which is faster? Please note that most CPUs have multiple integer units, and only a single floating point unit.
So much for slowing things down (perceptibly). Most people do not use spreadsheets for heavy duty numerics work. Most people do not know about propogating error terms in calculations.
The original spreadsheet (Visicalc) was coded to run in a minimal amount of memory. The use of floating point arithmetic could be excused. The text-based SC spreadsheet ALSO uses a minimal amount of memory. But current "general use" spreadsheet programs use megabytes of RAM. They should use accurate math as much as possible. If trig, log, etc. functions are used -- yes, I can understand putting the calculation into a floating point domain. Or, if explicit data typing is used. But not for casual use.
I want EXACT representation if at all possible. And it is. And it isn't difficult. Why does a simple training language like Scheme support this, and not a juggernaught like Excel?
Just another "Cubible(sic) Joe" 2 17 3061
I think m$ just need to create a new multiplication standard. An ISO standardisation process and some kickbacks is all it takes. I tell you next year we will all be doing multiplication this way.
But, nobody uses Excel for important business or financial decisions, do they?
OOOPS!
--- Hindsight is 20/20, but walking backwards is not the answer.
Why does this reply make me think of lolcats?
My God! It's full of eval()'s.
Ah, you picked the simplest possible example. Let's instead suppose I want to calculate 1/3 + 1/7 + 1/11.
First step, I have to find a common denominator. Simplest way to do that is to multiply the three existing denominators. That's two integer multiplies and gives me 3*7*11 = 231. Next step, need to figure out the numerators. The first one is 1*7*11=77 (two more multiplies), next one is 1*3*11=33 (two more multiplies) and the last is 1*3*7=21 (two more multiplies). Now I can do my addition, 77+33+21=131 (two integer adds). Okay, I've got 131/231 now. BUT, if my fractions aren't going to get really out of hand I need to make sure that fraction is in simplest form. Maybe somebody can come up with a better algorithm but my first thought is to prime factorize both numbers. Prime factorization requires dividing a number by all the primes up to it's own square root. So let's take the denominator. We do a square root (let's use an integer approximation and round it up), which gives us 15. So now I need to do about eight divides to check for prime factors (assuming I'm smart enough to only try odds and 2, but I don't have a big table of primes handy). The top is another square root and about six divides. A few comparisons to see if I can eliminate any common factors, then some divides to do the elimination (which I don't have in this case).
Whew. Okay, what's the damage? In this case I've got a grand total of 8 multiplies, 2 adds, 2 square roots (that's going to be a biggy), 14 divides and a bunch of comparisons.
Compare that to a pair of floating point adds. And that's for three SMALL numbers. Imagine what would have happened if they'd been big ones! The prime factorization would have been a lot bigger and the square root would have been harder. If I'd found common factors there would have been some more division to do.
Note that I've got to be really careful and check for overflows at every step (which probably takes more time than actually doing the calculation itself). If an integer overflows without me noticing I'm in deep trouble. If a float overflows I've just got a bit of a loss in precision (which isn't great, but it's better than wraparound). That makes it very important to make sure fractions stay in simplest form as well, in case you figured on dropping that part.
Okay, ready? Let's do a compound interest problem. On second thought, let's call it an exercise for the reader.
Most modern processors have several floating point units as well as several integer units. The floating point math tends to be faster nowadays too. Also, multiple math units don't do you any good when you can't do out of order execution. There are quite a few steps in that little calculation that can't be done out of order.
In addition to all this being slow, it's misleading as well. How often in real life does someone have a number like 0.1 (which can't be represented precisely in floating point binary, incidentally) and really mean PRECISELY 1/10? Pretty much never. They mean 0.1, or maybe 0.10, or even 0.10000000. So you see, you have to know about significant digits anyway. Except your "Accusheet" is misleading me into thinking the answer is precisely 131/231. It's not. It's 0.6.
Now, autoformatting of spreadsheet cells based on significant digits might be kind of a cool feature.
1. Buy shares in a stock
2. Pump up the share price to $65.535
3. Immediately sell shares at $100.000
4. Profit!
I'm not sure that I care where Microsoft Excel fails and where it doesn't when it comes to discovering the pattern of failure. If I were a Microsoft Excel user I wouldn't be allowed to inspect the program to see what it's really doing with my data, fix the program (no matter how expert a programmer I may be), alter the program (in violation of the license), or help my community by sharing my improved version of Excel. Then there's the hypocrisy of how proprietors (also known as monopolists) are treated compared to free software developers and distributors—knowing that the program fails where it shouldn't would be enough for people to cry foul and either stop using or never start using a free software program that exhibited such a bug. We rarely hear serious discussions of one's software freedom. Instead, we're encouraged to push that discussion aside in favor of exclusively stressing technocratic ends. Not hearing cries of "Dump Microsoft Excel Now!" or something calling for a switch to a free software spreadsheet (like Gnumeric or OpenOffice.org's Calc) is saddening. Please take this opportunity to learn more about software freedom.
Digital Citizen
more about 65535
Er, no. That would be 1/2, not 1/3. (And you mean "denominator".)
It needs to do two integer adds, and two compares. If the denominators weren't equal, it would also need to go through several more operations to find a common multiple of the denominators and adjust the numerators correspondingly; OTOH, this doesn't really invalidate your point, since its not a lot of operations, and they are all integer operations.
Bill: "Roll it out!"
Oh please.
I use Excel for hydraulic calculations. Yes Excel has accuracy limitations at about the 7th decimal place. Engineering calculations are rarely done to this level of accuracy.
If you a sending probes to the moon and planets, yes you need more accuracy, but for my needs, the ripple on the surface of the channel or the additional friction from the slime on the wall of the pipe is many orders of magnitude larger than any inaccuracy introduced by a spreadsheet.
If my call is important, why am I talking to a recording?
850 x 77.1 = Pat Buchanan?
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Maybe it should be called SIAG Office?
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
Bloated? Hardly. BCD isn't that difficult. Slower, yes, but if you need speed, you don't use a spreadsheet.
FYI, most databases use BCD for numeric fields. That's why Mike Cowlishaw, IBM's senior floating-point guru, managed to convince them to add a dedicated decimal floating point unit to their Power6-processors.
xkcd is not in the sudoers file. This incident will be reported.
> Scientific computation uses IEEE floating point pretty much exclusively. You just round off the last digit or so.
Perhaps a slight simplification of the IEEE standard there? It's dark magic to me...
But yes, an accountant needs guarantees that every last cent is accounted for, and I certainly want the last digit of precision in my ints!
I used to work for a company that produced a business system which used binary floats for representing currency values. The accountants were furious. You will not find an accountant who will accept a few cents short of balance just because you blame it on your architecture's inability to represent 0.1 accurately.
xkcd is not in the sudoers file. This incident will be reported.
> When adding 1/3 + 1/3 + 1/3, the computer needs to do 4 integer adds.
And a GCD + two divisions, although that can often be delayed. But you're right, spreadsheets should use exact arithmetic whenever possible. If my TI-89 could do it, why not them?
xkcd is not in the sudoers file. This incident will be reported.
> Maybe somebody can come up with a better algorithm but my first thought is to prime factorize both numbers.
:-)
There's an "Euclid" here who says he has come up with a better algorithm
xkcd is not in the sudoers file. This incident will be reported.
This bug does not appear in Excel 2003 Service Pack 3, which was released a few weeks ago. That build number is 11.8169.8172.
But is 065535 (octal) prime? What about 0x65535?
LedgerSMB: Open source Accounting/ERP
Neither is prime; 65535 in octal is 27485, a multiple of five, and 65535 hex is 415029, a multiple of three. I really wish some of the old 6502 representation of Base-n numbers were still used; the hex value you asked is $65535, but I'm not sure about the octal, however, as it's been a very long time.
Try 4369 * 15 (which should equal 65535).
I think MS loves such things as they provide a good publicity to them ;)
Nothing comes perfect in this world, after all the world is to achieve the perfection.
Complete Web Hosting Solutions at eUKhost.com
5 ends in a 5.
QED
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife