Profit or loss in finance, life or death in healthcare

Over the past couple of years we have highlighted cases where OOXML gets its math wrong or witnessed incidents where its tight and correspondent (but not OOXML-compliant) Microsoft Excel got its math wrong too (e.g. Office 2007, other versions which received bad patches). This says a lot about quality assurance at Microsoft and also about sloppiness at ISO.

Examples that are worth bringing attention to again:

• Buggy Microsoft Excel Patch Causes Bad Math



• Microsoft Excel fails math test



• Trouble In Microsoft World Over Calculator



• Microsoft: Excel Bug Doesn't Add Up



• [OOXML] Mathematically Incorrect



• OOXML: The Formula for Failure



• UK children's charity says goodbye to Excel

The only news is that Rob Weir has just added another problem to the pile. It's a very detailed post and as we mentioned very briefly the other day, Microsoft et al continue to hide OOXML from the public, thus leaving little or no time for scrutiny while it is crucial (a further delay seems possible).

So Excel is off by 2% or so. Do we really care. It's just money, right?

The problem is that the function in OOXML is defined incorrectly, from the financial perspective. The discount rate is the discount from the redemption value, not the discount from the purchase price. So the first term in the formula should be (redemption-par)/redemption, not (redemption-par)/par. If you make this change, then the calculated value matches the value Excel gives.

[...]

What would be normal practice would be to take the definitions, as given in the OOXML text, and to calculate the values according to the definition provided in the text, and then to compare the resulting values with what Excel returns. That would provide a useful double-check of the definitions in the text. But OOXML doesn't do that. The example here are mere fluff and provide no additional assurance to the implementor.

The discrepancy here also indicates that no one has actually reviewed these formulas for accuracy. Errors like this are immediately evident, but only if you look. The fact that things like this have escaped the notice of Microsoft, Ecma TC45, their Project Editors, 80 NB reviews, the BRM experts, and the eagle eyes of ITTF, should make one have considerable concerns over the the sufficiency of the Fast Track review and approval process.

Yet another bug as a standard? Does anyone even care? Does anyone care to actually implement this bug to ensure validation, which does not (and never will) ensure compatibility and inter-operability with Microsoft Office? Does Microsoft care? Hardly. As Tim Bray said quite recently, "what Microsoft really wanted was that ISO stamp of approval to use as a marketing tool. And just like your mother told you, when they get what they want and have their way with you, they’re probably not gonna call you in the morning." ⬆

Bill Gates: "No! There are no significant bugs in our released software that any significant number of users want fixed."

"FOCUS: Oh, my God. I always get mad at my computer if MS Word swallows the page numbers of a document which I printed a couple of times with page numbers. If I complain to anybody they say "Well, upgrade from version 5.11 to 6.0".

Bill Gates: "No! If you really think there's a bug you should report a bug. Maybe you're not using it properly. Have you ever considered that?"

FOCUS: "Yeah, I did..."

FOCUS Magazine, 1995