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.
This is the most devastating bug in years. Heaven have mercy on us all.
Just disrupt the deflector shield with a tachyon burst.
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!
Dunno, works just fine in my copy of 2007...
If you want news from today, you have to come back tomorrow.
To all people in science and engineering (I know lots of them) using Excel to analyze their data...
Years ago I wrote a parser and interpreter for MS Excel. At that time, the numerical representation was not IEEE floating point, but a truncated, poor cousin (8 bit) of a decent float implemetation called "RK numbers". I recall that I needed to interpolate and provide semi-randomized numbers for the gaps in the number line that 8 bits (mantissa + ordinate) would incur.
I wonder if MS still uses this implementation - which goes back to the early 1990s. It's a propietary, gappy implementation that was based, I think, on Mac / Motorola implementations.
Just my cut on it - I may be off base.
Open a Google Docs spreadsheet. Type =COMBIN(55,27)
-- Subvert the dominant paradigm. Repeat as desired. http://ownlifeful.com/
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
Try this
:^@
Alt-F11 (to get into VBA mode, or Menu-Tools-Macro-Visual basic editor)
Ctrl-G (immediate window)
msgbox (20123 + 10)
You get 20133 as you would expect
try:
msgbox (20123 + 20123)
d'oh - can't handle this, must wait for advanced version of the software to come out
I hear you brother, I specifically look for these types of errors when I am reviewing the code on open source spreadsheet programs. I am about 90% of the way through Gnumeric 1.0.1 and I should ready to put it into production in about another six months.
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.
...did not copy this.
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).
If I were given requirements as given by the author of the summary, I don't think I can figure out a way to screw it up so horribly, consistently, and intentionally. It boggles the mind how to implement this so incorrectly - treating 65536 as a hex (0x10000) and then a decimal (10,000) is off by a factor of 0x10, or 10 depending.
At least the pentium errors were explicable - incorrect lookup tables sure. Randomly interpreting hex numbers as decimal, incorrectly? Wow....
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 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
Here's a tip. The same fuckers wrote the application and the kernel, and we hate them, and no one wants your snarky effort to show you took a high school intro to computers class.
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
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....
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
If this had been a bug with, say, some iPhone spreadsheet program, it would have been found and posted launch day.
Why has it taken so long for someone to find this? Other than the plausible explanation that MS' push for people to upgrade isn't going so well...
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.
I think it is fixed in Office 2003 with the SP2 update.
Should be enough for anybody.
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.
Gnumeric 1.0.1
Hurr hurr.
But seriously, if you want to know your code is secure, you take the code and you audit it. If you want other people to tell you the code is secure, promise, cross their heart, hope to die, etc etc (but the EULA says you can't hold them to it) then by all means, take their word for it.
If you audit the code and it takes you 12 months to do the most recent major version, it should only take you a few more months to audit the changes to that original code (you did take notes, right?), and a short while more to audit the changes during the audit of the patches... then you're all caught up, and you can audit patches as they come out.
Who knows, if you get good at it, people will start taking your word for it.
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.
65,534 should be enough for anybody
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.
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.
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!
Weird. I can't get it to appear in my work copy of Excel 2003. Nor can I get it to appear in any of the apps on any of my systems.
Maybe some patch caused/fixed it? Or else it could be another CPU bug.
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. :^)
Are you a student or teach/work at LSU? That's not my take on how the ITPC works.
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.
With open source, the fix will be available within minutes, but then everyone would have to go and recompile the product, or in the least download a new build and install it. So the time lost to the business is still there, even if they were using open source software. Oh, and they can't sue anyone if they were using open source either.
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.
So, you are saying that Microsoft programs are really no different from Open Source, except that they don't give you the source and (currently) cost you an arm and a leg?
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.
Not true at all. You could be entitled to compensation of damages up to five (5) US dollars under EULA's limited liability clause. No, I'm not joking. Go read Microsoft EULAs (if you're a maschocist like me.
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?
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.
When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours.
Because your god threatened you with an eternity of torture?
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
You're a lying sack of shit, the EULA says you can recover up to the cost of the software, and no more.
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.
If you play around with it for a couple minutes, this has got to be some kind of a display bug. Excel knows the number is correct, since just adding 0.001 gets it out of its funk. Maybe it's showing us binary of 65536? 100000 (plus 00000000000) would kind of make sense here...
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!
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 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
Just ran it through maxima, it agrees that the result is 3824345300380220.
wtf is this "Lameness filter"? I had to remove the code sample from Maxima in order to get this past some filter on 'junk' characters. Grrr.
...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!
...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.
You can use Office 2003 if you have it - MS has an add-in that allows it to open/save the 2007 file formats. Sorry, no URL handy.
- T
Comment removed based on user account deletion
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!
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
Years ago, if you entered 2.11-2.1 in any windows 3.1 application using the system math library, you got 0. This was a huge bug that went unpatched for a long time due to the unavailability of public Internet access at that time. IIRC it survived even the 3.11 WfW version.
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
=(2^16) returns 65536
=(2^16)-0.000000000009 returns 1000001
The raw XML saves the result with 12 decimal places.
r="A1"
f>850*77.1
v>65534.999999999993
r="J1"
f>(2^16)-0.000000000009
v>65535.999999999993
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).
I've been billing at $71.10 per hour for years due to this bug.
You guys just ruined my gravy train.
Bastards.
Yeah and into the late 1990's he was still proclaiming the Internet to be just a "passing fad". This Excel bug is just another example of the crap from that company, if it weren't for the multitude of PR firms working full time to create various myths of greatness, we'd all be (collectively) saving billions of dollars per year.
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.
No, we look at the kernel dump and pass the bug along to the windows team, who will then insist that the bug was fixed in a more recent drop (that isn't yet available).
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?
Not much has changed in 10 years it seems. In '99, a paper appeared describing the abysmal state of statistical accuracy in MS excel. Nobody requiring 100% reliability of the results should trust *any* version of excel without carefully double checking the calculations independently.
I am amazed that even people here are surprised that spreadsheets have bugs.....
Now we know how they came up with all that Global Warming data!!!
The 4*5 can be written as 2*2*5, which can be written as 2*10. This guarantees that the last digit is a zero. (Any number multiplied by ten ends in a zero).
So Octave is wrong.
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.
Or maybe they thought of this and use another internal representation?
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.
well alteast we will have some strong economic growth after countries migrate to office 2007
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
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
... 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? ;)
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.
"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.
Cost or Value ? There's a big difference.
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!
Not a bug in Excel 2003 SP2.
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.
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.
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?
Math is hard!
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]
...maybe MS caved in to hard drive manufacturers brand of math to keep everything "standard"?
-S
"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
Excel should use algebra for this:
borrowed from a wiki:
65,535a = 65,535b (multiplying both sides by the real number)
100,000a = 100,000b (multiplying both sides by the "real" number)
65,535a2 = 65,535ab (multiplying by a on both sides)
100,000ab = 100,000b2 (multiplying by b on both sides)
65,535a2 - 100,000ab = 65,535ab - 100,000b2 (subtracting the above two equations to make one)
65,535a2 - 65,535ab = 100,000ab - 100,000b2 (subtracting 65,535ab and adding 100,000ab to both sides)
65,535a2 - 65,535ab + ab - b2 = 100,001ab - 100,001b2 (adding ab and subtracting b2 from both sides)
65,535a(a-b) + b(a-b) = 100,001b(a-b) (factoring out common terms)
65,535a + b = 100,001b (removing common terms)
65,535a = 100,000b (subtracting b from both sides)
65,535b = 100,000b (substituting a for b, remembering that they are equal)
65,535 = 100,000
Freaking Euros. We FINALLY do something metric and all you can do is bitch about it.
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.
According to the logic of Quantum Mechanics, if a function is discontinuous, then it's just the way the universe works, and the numbers inside the break are declared "forbidden". Remember, kids, searching for causes is heresy! We can't ever really know how things "really are" and it is pointless to ask the question, so fire up your probability calculations and resign to the fact that answers between 65535 and 100000 must forever remain undetermined.
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?
Python doesn't return the correct value either:
>>> 850*77.1
65534.999999999993
Great language you got there guys.
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!
Haha, Microsoft must be using the Java libraries for math functions. Not IEEE compliant, and broken, much like Java itself.
Seriously, what can we expect from a bunch of code monkeys.
Mod parent up! Not EVERYTHING is a conspiracy!
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
65535 is not a prime number.
:)
Demonstration:
65535 = 850*77.1
65535 = 85*771
65535 = 85*257*3
65535 = 17*5*257*3
Call to 1 75 25 73 and you will get an answer to your problems
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?
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.
2003 != 2007
Note to self: learn to read.
You has a lighweight Pentium-M without MMX/SSE instructions!!!
The SIMD instructions are useless in internetworkings and javas!!!
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
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.
Try using Microsofts print to PDF functionality with a serious workbook (50+ pages of graphs, etc) or creating rather complex models using VBA + multiple workbooks and Excel 2007 breaks down in an impressive fashion.
My company has gone to having Excel 2003 and 2007 installed on our PCs for various purposes. We need 2007's advanced OLAP pivottable connections to download and upload data to/from our models, but we need 2003 to actually calculate the model. Microsoft has acknowledged that our calculation issue is a bug and they are "working on it". And have been since March...
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."
That sounds like it's not a programming bug, but more of a logic bug instead.
Don't be apathetic. Procrastinate!
I think Leasburg, MO (zip code 65535) should sue MS for defamation of character.
These are good, down to earth people who do know how to add, dammit!
http://en.wikipedia.org/wiki/Leasburg,_Missouri
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."
...and bring this to JSH's attention. after all, he was able to solve FLT so easily - he should be able to figure out the details of this for MS in no time.
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.
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.
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.
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.
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?
I've heard stories of the same kind
I've heard stories of the same kind too - in your previous comments.This is the same shit you post all the time to slashdot.
Please, shut the fuck up.
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
100,000 should be enough for everyone!
To Microsoft(tm) excel(tm) 2005(tm)?
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!
To answer your question:
The "scientific" (more like engineering) math packages are tested for numerical accuracy and designed for it *from the start*.
You have chosen, instead of those, to use a cheapie (hey, it's bundled, so it's "free to me"!) product from a company that is renowned for quality problems. Numerical accuracy is not a core part of the design and testing of Excel, to judge from the reported problems over the years.
Cheap has its price... but if you really wanted cheap, you could have gone for the various FREE numerical software packages.
Just admit that the real reason you chose Excel is because you are lazy. Most people are.
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,...
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.
Did I say value, or did I say cost? I'm pretty sure I only said one of them. You'll have to find some esoteric method of figuring out which, though, since you apparently can't fucking read.
Remember "Microsoft Multiplan"?
From a posting I made a while back for the TI-99 version...
I finally found the Multiplan Bug I mentioned months (years?) ago...
It is located on the wht ftp site under "/datasheets/Official TI
addenda and data sheets", "Multiplan addenda.max".
The bug affects the SQRT function.
"If a square root is taken of a number less than one AND contains an
odd number of zeros before the first significant digit (i.e. 0.01,
0.000123), Microsoft Multiplan will calculate the square root
incorrectly by a factor of ten. Currently SQRT(0.01) is calculated as
1.0 and SQRT(0.000123) is calculated as 0.110905."...
It goes on to give an ugly work-around.
My version when tested had this bug. Has it been fixed in later
versions (RAG, 80 column, TI patched, etc)?
And does this bug exist in Multiplan on other platforms?
It is evident by this bug that Microsoft does not use the built-in
floating point routines in the 99/4A, esp. the square-root GPL
routine which does not have this problem. Also, I seem to remember
the number of significant digits differ between MP and the TI
routines.
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
So, the market share of Linsux users seems to be about 572 or so, and you "winners" clearly know how to spend your weekends. Have you ever kissed a girl?
Alex
more about 65535
I always wondered how the RIAA got it's strange and obscure figures...
Our profit increased by 52.59%, thanks to Micro$oft Office 2oo7!
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.
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