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

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

*From*:**"Dennis E. Hamilton" <dennis.hamilton@acm.org>***To*: <office-formula@lists.oasis-open.org>*Date*: Sun, 24 Jan 2010 12:26:35 -0800

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 apparent. 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 approximations.]" 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 specification.]" 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] http://lists.oasis-open.org/archives/office-formula/201001/msg00071.html Sent: Sunday, January 24, 2010 07:50 To: office-formula@lists.oasis-open.org Subject: [office-formula] Numeric Models Greetings! 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 models? 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 -- Patrick Durusau patrick@durusau.net 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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

**References**:**Numeric Models***From:*Patrick Durusau <patrick@durusau.net>

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