Soffice is compatible with actual math instead of Microsoft

Thanks to Slashdot for revealing a serious bug in Microsoft Excel 2007. It seems that in Microsoft's popular spreadsheet application, multiplying values which would result in a product of 65535 (e.g. 10.2\*6425), produce wildly inaccurate results.

It's amazing that a monopoly which can convince hundreds of thousands of beta testers to pay for the privilege of beta testing would productize an error this severe. I'm not talking about the kind of cumulative round-off errors that can be captured and tamed with interval math. I'm talking about errors that make you say "Whoops, I just paid 52% too much for that house, gave that patient 52% too much medicine, built that bridge 52% too long..." The Microsoft Excel EULA probably indicates that you're not supposed to use their application for prescribing medicine, designing nuclear power plants or calculating the optimal central bank interest rate, but I also suspect that Excel is used in many places it wasn't designed for.

Staroffice and other OpenOffice.org distributions could follow Microsoft's "standard" and tell us that 850 \* 77.1 is 100,000. But instead it appears to stick to relatively mundane base 10 arithmetic as it works in this universe. Regardless of how you feel about opensource software, a good QA engineer of a critical Excel spreadsheet should at least run their spreadsheet through starcalc or oo.org calc and use their slide rule to double check any results where these applications disagree significantly.

Staroffice 8 gives the correct answer to these  arithmetic products, Microsoft Excel 2007 doesn't

Comments:

Post a Comment:
Comments are closed for this entry.
About

bnitz

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today