Re: [office-formula] Implementation-defined, Unspecified, and Undefinedbehaviors in OpenFormula

["David A. Wheeler" <dwheeler@dwheeler.com>]

robert_weir@us.ibm.com wrote:
 > Then I wonder if we truly need to have all of these items be
 > implementation-defined?  Or to ask the question differently, would there
 > be tangible user benefit, in terms of increased interoperability, if 
some
 > of these items were fully specified, knowing that some implementations
 > would then need to change their code in order to conform, and that they
 > would need to deal (perhaps with version-conditional logic) with legacy
 > documents?

"Aye, there's the rub".  If the cost of forcing exact equivalence 
exceeds the benefits, then I believe that we should NOT force 
unnecessary equivalence, and that "implementation-defined" is what we 
SHOULD say.   For years we've been trying to eliminate 
"implementation-defined" areas, so I'd be surprised if we could now come 
to some agreement on many of these, but by all means let's talk.

There are many areas where we DO force specific interpretations, even 
though spreadsheets differ, because they DO impact interoperability. 
For example, several spreadsheet implementations' ordinary string 
operations start counting positions at 0; others start counting at 1. 
Neither is the "right answer", but failing to agree on a convention 
would make nearly all the string operations non-interoperable.  So we 
settled on using 1 as the starting number.  And so on.

But there are diminishing returns; at some point, it's better to give up 
and leave some things implementation-defined.

 > However, in other areas, like what SUM() does with a empty argument list,

Here I think there is legitimate disagreement.  Some believe that this 
should be Error.  On the other hand, it's perfectly reasonable to argue 
that "0" should be the result; it's even mathematically clean.  I see no 
benefit to pressing this issue; this construct simply doesn't happen in 
normal spreadsheets.  Why do we want implementors to make changes to 
their implementations if there would be no improvement in 
interoperability?  I think here, the costs to change clearly exceed any 
benefit to interoperability.

 > I'd like to see us come up with a good reason why it is a good thing to
 > have a feature be implementation-defined.  Saying "mathematicians
 > disagree" or "different implementations do different things" doesn't 
sound
 > like a particularly good reason.

Why not?  If there's no "right" answer, and disagreement does not 
significantly impact interoperability, then there's no benefit to trying 
to find a right answer.  It all comes to down to cost vs. benefit.

 > That's the analysis I'd like to see:  What is the user benefit if we
 > eliminated these differences versus what would be the downside.
 >
 > The nice thing here is that any choice is defensible.  It is not like 
any
 > of them are wrong.  We're not redefining the Gregorian calendar or
 > anything.  So I'd just pick one, based on the majority (or plurality if
 > that is the case) behavior. Or do whatever Excel does here, if that 
makes
 > Doug happy.  I'd certainly have no hesitancy to add an "if" statement to
 > the Symphony code if it were necessary for us to accommodate this.

 > What do people think?  Is this an area that is worth cleaning up rather
 > than trying to standardize a snapshot of the legacy application mess?

I don't see it as a mess.  There are few examples, as you noted.

By the way, I skimmed through your spreadsheet.  "=3>=TRUE()" is NOT 
necessarily an operation mixing types.  TRUE() may be a Number (it _IS_ 
a Number on OpenOffice.org, Lotus, Quattro Pro, and many others); when 
Logical isn't a distinct type, they're the same.


--- David A. Wheeler