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

*Subject*: **More on 6.3.4 Infix "/"**

*From*:**Patrick Durusau <patrick@durusau.net>***To*: OASIS ODFF SC <office-formula@lists.oasis-open.org>*Date*: Wed, 14 Jan 2009 10:45:59 -0500

Greetings, I am still trying to work out what are/are not legitimate inputs for the infix "/". Reading the syntax: *Syntax:* /Number/ /Left/ / /Number/ /Right/ 6.1 says that "Number" is a type or pseudo-type, but Number (4.2) says: > A number is simply a numeric value such as 0, -4.5, or $1000. Numbers > *shall* be able to represent fractional values (they *shall not** *be > limited to only integers). The "number" type *may* be displayed in > many different formats, including date, time, percentage, and currency. > So does "number" include all those formats or are they "types?" Moreover, when I read Complex Number (4.3) I read: > It is the explicit intent of this specification to /permit/ > applications to support complex numbers using the traditional infix > operators ("+", "-", "*", "/", and "^"), even for comparison operators > such as = (equal to) and <> (not equal to). > Maybe we are approaching this from completely different perspectives. ;-) Let me say what I think my perspective requires for this case and then someone can offer theirs and we can see where we wind up. To define a function it is necessary to: 1. Specify the inputs by type 2. Specify the mathematical operation 3. Specify the output of the function by type 4. Define what error conditions, if any, may exist and what happens in those cases. Such as input is of an incorrect type. (Output being of the wrong type is simply non-conformance.) It is entirely possible to define the infix "/" operator for inputs that include real numbers, complex numbers or even polynomials. Ah, question: Is the reason for saying things are permitted to get around the notion that if it isn't explicitly permitted then it is forbidden? Well, I think that is a tough choice we have to make in order to have real interoperability. For example, if we define the infix "/" operator to require real numbers for input and to produce a real number for output, then any time I get a formula that claims adherence to OpenFormula, I have some assurance that I can process every instance of the infix "/" operator, assuming the formula does adhere to that OpenFormula definition. If on the other hand, we make the same definition and then we say, a file format or application may also use the infix "/" to represent division of complex numbers or polynomials, then my assurance that I can reliably interchange information has taken a real hit. True, we could make those separate levels of conformance, 1st level - real numbers only, 2nd level - real numbers + complex numbers, 3rd level - real numbers + complex numbers + polynomials, and have a mechanism to signal which one I am encountering but we would have to do that *explicitly* within the standard. The point being that in order to facilitate interoperability standards must make choices about what can or cannot appear in a format or formula. The best we can do is to try to be clear about the choices we did make. Closer/farer away? Hope everyone is having a great day! 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)

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