RE: [office-formula] Implementation-defined, Unspecified, and Undefined behaviors in OpenFormula

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I recall "discretionary" being used in cases such as arithmetic precision,
maximum dimensions on tables, and other cases where an implementation may
place a limitation (e.g., on the maximum length of the dc:creator string, in
presented characters, that will be put into some user-readable
presentation). 

Although some implementation-defined aspects may be of this nature, it might
be useful to single them out.  I certainly agree that there should be a
specification of how each conforming implementation handles
implementation-defined features.

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Thursday, June 11, 2009 21:19
To: office-formula@lists.oasis-open.org
Subject: Re: [office-formula] Implementation-defined, Unspecified, and
Undefined behaviors in OpenFormula

[ ... ]

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.

That said, I'm sure we can come up with some good reasons.  For example, 
the exact numeric precision is not specified.  This is not because having 
consistent floating point behavior would not be a good thing.  The issue 
is that enforcing such uniformity, across machine architectures, would 
essentially mean that we avoid on-chip floating point and do it via 
emulation, which would perform poorly and be expensive to implement, with 
little incremental user 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.

[ ... ]