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

*Subject*: **Infix Operator "="**

*From*:**Patrick Durusau <patrick@durusau.net>***To*: "office-formula@lists.oasis-open.org" <office-formula@lists.oasis-open.org>*Date*: Thu, 10 Dec 2009 07:17:41 -0500

Greetings! We say for infix operator "=": > Returns TRUE if two values are equal. If the values differ in type, > return FALSE. If the values are both Number, return TRUE if they are > considered equal, else return FALSE. If they are both Text, return > TRUE if the two values match, else return FALSE. For Text values, if > the calculation setting |table:case-sensitive| is |false|, text is > compared but characters differencing only in case are considered > equal. If they are both Logicals, return TRUE if they are identical, > else return FALSE. Note that, like most other functions, errors are > propagated; error values /cannot/ be compared to a constant error > value to determine if that is the same error value. > Err, don't we define equivalence of text, logicals, etc. elsewhere? Such that this paragraph should read: "Returns TRUE if two values are equal. Returns FALSE if two values are not equal. If the values differ in type, returns FALSE." where the comparison tests for various types are defined elsewhere. I am not sure what to make of: "...like most other functions...." That isn't a useful statement. If elsewhere we define that error values cannot be compared, that is sufficient. BTW, is the rest of this section: > Note that the result of “1=TRUE()” is implementation-defined. On > implementations where logicals are implemented as numbers, this is > true. However, on implementations where logicals are a separate > distinct type, this would be normally be false. > > 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 “==”. > An extended, non-normative note? If we really want to say "implementation-defined" and have that mean something we need to add other text to OpenFormula. Thanks! Hope everyone is having a great day! Patrick PS: I am systematically deleting the text: "Due to the way conversion works, logical values are converted to numbers." It really isn't necessary to repeat all possible information at every opportunity. -- 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)

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