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

[robert_weir@us.ibm.com]

The language on precision is:

"This specification does not, by itself, specify a numerical 
implementation model, though it does imply some minimal levels of accuracy 
for most functions. For example, an application cannot say that it 
implements the infix operator ?/? as specified in this document if it 
implements integer-only arithmetic.

In practice, applications tend to use at least one IEEE 754-1985 binary 
floating-point representation, using at least the 64-bit representation 
and possibly larger widths for intermediate results. When IEEE 754 
representations are used, results such as Inf (infinity) and Nan (not a 
number) are considered an Error value. Applications may use IEEE 854-1987 
(which covers decimal arithmetic). In general, applications are encouraged 
to use appropriate standards for their numerical models. This means that 
applications will often not produce ?exact? results, but only approximate 
results for a large number of places."

I think I would call this "implementation-defined" and we probably want to 
say that explicitly in cases like this. We might also wanb to rephrase 
this from a statement about the specification, "the specification does 
not...", to a statement about the implementation, e..g, "The numerical 
implementation model used by a conforming OpenFormula expression evaluator 
is implementation-defined", or something similar.

-Rob


"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/12/2009 
01:52:18 AM:
> 
> Subject:
> 
> RE: [office-formula] Implementation-defined, Unspecified, and 
> Undefined behaviors in OpenFormula
> 
> 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.
> 
> [ ... ]
>