[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Implementation-defined, Unspecified, and Undefinedbehaviors in OpenFormula
> > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]