OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office-formula] Numeric Models - A Proposal

More good questions.  We probably need to move a lot of our discussions to
JIRA issues so that we manage through them as systematic approaches become

A. I agree that the second paragraph of 2.6 and the highlighted note should
be nuked.  An OpenFormula-hosting specification might specify more about the
numerical model, including requiring results to be compatible with those
achievable using such-and-such standard.  I don't think this belongs here.

B. With regard to using implementation-defined and
implementation-determined, I think we need to be careful about using those
terms here.  An OpenFormula-formula hosting specification should be able to
establish its own normative conditions on what is required of its conformant
implementations in some preise way.

C. I can see saying quite a bit more about the Number types with regard to
how numerical results need only be carried approximately to some degree of
precision. Here's my offering for consideration of the OpenFormula SC and
the ODF TC:

   C.1 "Where the representation of a numerical type does not provide for
precise representation of the exact result, or the result is not exactly
expressible (e.g., the value of =PI() or =SQRT(2) or =1/7), a nearby
representable value SHALL be employed as an approximation.  When a result
exceeds the range of representation for the numerical type implementation or
is not mathematically determined, an error result SHALL be provided.  [Note:
How an OpenFormula hosting deals with error results and what it allows in
regard to them, the OpenFormula-hosting specification can deal with.]"

   C.2 "Formula evaluation shall employ the exactly-represented
(approximate) values in deriving further (approximate) results. [Note: All
four readings of this sentence are intended.  Once an approximation is
determined, that approximation is itself a precise value of the numerical
type, however inaccurate it might be in terms of how it was arrived at.  In
addition, there are evaluations that deliver precise results (e.g.,
"=(1/7)<0") regardless of the degree to which their operands are

   C.3 "The representation of values expressed in numerical constants in a
formula SHALL be with approximated values in the same manner (C.1)."

   C.4 "Values of numerical type, although precise, might not have a precise
representation as a literal constant expressed in a text string.  Automatic
conversion of the value of a numerical type to a text value SHALL produce an
approximation of comparable precision when the precise value is not
expressible (e.g., because of representation-radix incompatibilities among
floating-point forms).  The text string form SHOULD be such that when
interpreted in a formula as a value of the same numerical type, the same
evaluator will arrive at the original numerical value representation.  
   "[Note 1: this condition is not about the formatting and presentation of
displayable results by a document-format consumer or producer, the
derivation of which is subject to many other conditions separate from those
involving OpenFormula evaluations. Similarly, this condition is not directly
related to how numerical-type values are introduced by user entry using
formatted text.  Note 2: Ideally, automatically-derived text strings for
carrying persistent values of numerical types in document formats and
recovering such values on consumption of the format would preserve this
condition among processors implementing the same numerical type
representations.  Any conditions on fidelity of number-to-text-to-number
reproducibility in this case are established by the OpenFormula-hosting

D. I didn't look to see if the description of conversions and of specific
conversion functions handles the case of output-input reproducibility.  That
is worth investigating, though.

 - Dennis

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Sunday, January 24, 2010 07:50
To: office-formula@lists.oasis-open.org
Subject: [office-formula] Numeric Models


Eike objected to the deletion of 2.6 Numeric Models but did not say why.

As I read 2.6, it is entirely non-normative with the exception that it 
does not that unless an implementation (evaluator) has only integer-only 
arithmetic it cannot implement "/" as specified. That is worthy of a 
note under "/" but not an entire section.

Saying, as we do now under 2.6, that:

> 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.
Isn't helpful. What does "...encouraged to use appropriate standards for 
their numeric models." mean?

How does a user find out what "appropriate standards" for what "numeric 

We should consider Paul Cotten's suggestion about implementation defined 
vs. dependent in this context.

That is in conformance we should require disclosure of numeric models by 
standard and departure from those standards as a matter of conforming to 
OpenFormula. Not to mandate a particular numeric model or standard or 
conformance to a standard but at least give users the information needed 
to make an informed choice between evaluators.

Hope everyone is having a great weekend!


Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]