[OASIS Issue Tracker] Commented: (OFFICE-2385) 5.4.7 Infix Operator"="

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17585#action_17585 ] 

Dennis Hamilton commented on OFFICE-2385:
-----------------------------------------

Agreed.  That is not an useful note.  

If there is to be provision for allowing nearly-equal as an implementation of comparison of Numbers that are not exactly-represented integers, something other than a note needs to be said in the definitive part of this section.  

The "are considered equal" in the main description is pretty sneaky.  Something needs to be said about that.   Also, if we are going to deal with this, we need to account for its impact on the other relational operators too: "<>", <,", "<=", etc., all of which are influenced by what "are considered equal" or "are not considered sufficiently different" means.  Note that this situation applies regardless of the radix of floating-point representation, whether 2, 8, 10, 16, or some other integer value.

We could sharpen the treatment for OpenFormula by considering an ambient comparison tolerance within which two values of Number type are considered close enough to be regarded as equal.  This is a complex matter because we don't know the circumstances around the derivation of the compared Number values to know the degree to which the value being compared should be considered as approximate, so an ambient comparison tolerance is not a cure-all.  

Although we can define an ambient comparison approximation tolerance value, many implementations would require it to be 0 or an implementation-defined value. Although we would not need to fix the value for OpenFormula,  It is conceivable that an OpenFormula-hosting specification could provide for variability of the tolerance and specify that the the expected value be recorded in a document format, it is not clear what a conforming consumer could be required to do with it.  

Technical Note 1: It is difficult to specify such a tolerance value < 1 as a text string for a Number value without having to work around it also not being exactly representable.  (The C Language Standard Library file float.h has a form of this problem.)  Defining the value in a representation-neutral way as a text-expressed Number value is a challenge all by itself.  A scheme that uses integer values to express the tolerance relative to the trailing-digit position of the largest magnitude being compared might do it.  That is, the tolerance is relative to the lowest-order position in the Number with the largest magnitude.  [This is an alternative and straightforward way to express the exact tolerance value, epsilon, that Knuth uses in discussing floating-point comparisons.  Accepting integers allows the tolerance to be expressed without knowledge of the base or the precision of a floating-point representation.  It is nice that 0 means no tolerance, 1 means basically off by less than one in the one-least-signifcant place of the representation, etc. This is very different than directly expressing a relative-error tolerance, though.  I haven't checked the various IEEE floating-point representation standards for how comparison tolerances apply in those schemes. ]   

[Technical note 2: The situation is a bit more complex for Complex.]



> 5.4.7 Infix Operator "="
> ------------------------
>
>                 Key: OFFICE-2385
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2385
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: OpenFormula
>    Affects Versions: ODF 1.2 Part 2 CD 2
>            Reporter: Patrick Durusau
>
> General commentary under 5.4.7 Infix Operator "=" deleted.
> Created JIRA issue to call attention to it.
> "Note that in most implementations, numbers are computed using fixed-length representations in base 2 or 16, using a matissa and an exponent. This means that values such as 0.1 cannot be exactly represented (just as 1/3 cannot be exactly represented in base 10 using decimal notation). As a result, (0.1*10) will not have the same bit representation as 1. Since many spreadsheet users do not understand how computers typically represent numbers, applications may attempt to hide these differences by allowing "nearly" equal numbers to be considered equal, but applications are not required to do so.
> Note that in some user interfaces this is displayed or accepted as "=="."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira