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

[robert_weir@us.ibm.com]

> 
>  > 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.
> 

What's the cost in this case?  I think this is something that could be 
handled in a single if statement, along the lines of:

(if param_count == 0)
        return ERROR_CODES.ARGUMENT_ERROR;
else
{
        //do whatever you did before
}

So I think the costs are minimal.

By bias is this, from the user's perspective, and I'd recommend this as a 
principle:  If something should not be done, then doing it should be an 
error.  Only if detecting the error is too costly should we say it is 
unspecified.  That is the argument, for example, why C does not define the 
value of an uninitialized variable.  It is not because having these is 
good.  It is that detecting them was considered to be prohibitive for 
runtime performance.

>  > 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.
> 

There may not be any agreed "right" answer but that does not mean that 
anyone agrees that there should be three "right answers".  It is very 
possible that if we ranked our preferences here in the TC, they would be 
as follows:

1) Everyone does exactly what my implementation does
2) We all do the same thing, even if that means my implementation must 
change to follow the standard
3) No one changes their code and interoperability is reduced

I have no doubt that all implementors would state that their first 
preference is #1.  That is natural and is it obvious that this is not a 
viable solution, since we have conflicting behaviors today.  So the 
question is what is our 2nd preference?


>  > 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.
> 

Can you suggest a different example?

-Rob