Re: [office-formula] Implementation-defined, Unspecified, andUndefined behaviors in OpenFormula

[Andreas J Guelzow <aguelzow@math.concordia.ab.ca>]

On Fri, 2009-06-12 at 00:19 -0400, robert_weir@us.ibm.com wrote:

> 
> Let me know if there are any missing that jump out in your mind.  If there 
> are, then they may not have been consistently called out with the term 
> "implementation-defined" in the specification, and we should fix that.
> 
> 
> > > 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?
> > 
> > Re-examining these is a good idea.
> > 
> > However, I think that expecting "0 implementation-defined values" is 
> > both unrealistic and undesirable in most real standards, including this 
> > one.  In all non-trivial standards there are areas where there are 
> > legitimate differences, and trying to prematurely force a specific 
> > answer is simply undesirable.  Simply identifying those areas, so users 
> > know what to avoid, is a major benefit, even when we don't specify the 
> > specifics.
> > 
> 
> 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.  I think it is expected that 
> implementations will need to change their code to implement OpenFormula. 
> I'd be astonished if the did not.

You may be in for surprises. Whatever the OpenFormula standard says,
mathematical correctness is for some of us simply more important. Just
because everybody else disagrees to calculate a wrong answer dos not
mean that we have to follow. 

Having said that, this doesn't necessarily maen that the file format can
be accommodated: for example in Gnumeric typing 2^3^2 will always be 512
not 64, but of course as we write to ODF files or read from there we may
include parentheses to fix what we consider simply to be wrong. 

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

Well, sorry, but two of them are wrong. Once you say what ^ means, two
of them have to be 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.

You may not have that hesitancy, but I for example would hesitate. You
would need a really good reason to agree on the wrong answer. 
> 

Andreas
-- 
Andreas J. Guelzow
Concordia University College of Alberta